Re: Building two conflicting binaries from the same source

2022-11-03 Thread Bojan Smojver via devel
Thank you!

--
Bojan



4 Nov 2022 8:48:25 am Florian Weimer :

* Bojan Smojver via devel:

> Sure, it is easy enough to configure/build repeatedly and stash the
> results into non-conflicting paths of buildroot, but how does one then
> package this in %files sections into exactly the same paths?

See tests/data/SPECS/test-subpackages-pathpostfixes.spec in the RPM
source tree:

| Name:   test
| […]
| %description
| %{summary}.
|
| %package test2
| RemovePathPostfixes: .foobar
| Summary: Test2.
| %description test2
| […]
| %files
| /bin/hello
|
| %files test2
| /bin/hello.foobar
| […]

The key enabler is RemovePathPostfixes.

Thanks,
Florian
___
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 37 compose report: 20221103.n.1 changes

2022-11-03 Thread Fedora Rawhide Report
OLD: Fedora-37-20221102.n.0
NEW: Fedora-37-20221103.n.1

= SUMMARY =
Added images:1
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   6
Downgraded packages: 0

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

Size change of upgraded packages:   3.80 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Server_KVM qcow2 s390x
Path: Server/s390x/images/Fedora-Server-KVM-37-20221103.n.1.s390x.qcow2

= DROPPED IMAGES =
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-37-20221102.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  firefox-106.0.1-1.fc37
Old package:  firefox-105.0.1-2.fc37
Summary:  Mozilla Firefox Web browser
RPMs: firefox firefox-langpacks firefox-wayland firefox-x11
Size: 420.21 MiB
Size change:  4.53 MiB
Changelog:
  * Sun Oct 23 2022 Martin Stransky - 106.0.1-1
  - Update to 106.0.01
  - Require xdg-desktop-portal when file dialog portal is used.
  - Disabled file dialog portals on F37+

  * Thu Oct 20 2022 Jan Grulich  - 106.0-2
  - Enable upstream WebRTC code for screensharing on Wayland

  * Fri Oct 14 2022 Martin Stransky - 106.0-1
  - Updated to 106.0
  - Disabled PGO build due to rhbz#2136401

  * Fri Oct 14 2022 Martin Stransky - 105.0.2-2
  - Fixed crashes on multi-monitor systems (mzbz#1793922)

  * Wed Oct 05 2022 Martin Stransky - 105.0.2-1
  - Updated to 105.0.2

  * Fri Sep 30 2022 Martin Stransky - 105.0.1-2
  - Added fix for mozilla#1791856 / rhbz#2130087

  * Thu Sep 22 2022 Martin Stransky - 105.0.1-1
  - Updated to 105.0.1
  - Excluded i686 due to https://bugzilla.mozilla.org/show_bug.cgi?id=1792159,
https://bugzilla.redhat.com/show_bug.cgi?id=2129720

  * Tue Sep 20 2022 Martin Stransky - 105.0-1
  - Updated to 105.0

  * Tue Sep 06 2022 Martin Stransky - 104.0.2-1
  - Updated to 104.0.2

  * Tue Aug 30 2022 Martin Stransky - 104.0.1-1
  - Updated to 104.0.1

  * Tue Aug 23 2022 Kalev Lember  - 104.0-5
  - Use constrain_build macro to simplify parallel make handling
  - Drop obsolete build conditionals
  - Drop unused patches
  - Use build_ldflags
  - Drop hardened_build option
  - Re-enable s390x builds

  * Tue Aug 23 2022 Jan Horak  - 104.0-4
  - Rebuild due to ppc64le fixes

  * Mon Aug 22 2022 Eike Rathke  - 104.0-3
  - Update to 104.0 respin

  * Wed Aug 17 2022 Martin Stransky - 104.0-2
  - Added build fixes

  * Tue Aug 16 2022 Martin Stransky - 104.0-1
  - Updated to 104.0

  * Fri Aug 12 2022 Martin Stransky - 103.0.2-1
  - Updated to 103.0.2

  * Thu Aug 04 2022 Martin Stransky - 103.0.1-2
  - Added arm build fixes by Gabriel Hojda
  - Enable VA-API (rhbz#2115253)

  * Tue Aug 02 2022 Martin Stransky - 103.0.1-1
  - Update to 103.0.1

  * Tue Jul 26 2022 Martin Stransky - 103.0-1
  - Update to 103.0
  - Disabled ppc64le due to webrtc build failures (rhbz#2113850)

  * Thu Jul 21 2022 Fedora Release Engineering  - 
102.0-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild

  * Wed Jul 13 2022 Martin Stransky - 102.0-3
  - Update preference logging.
  - Added ARM fixes by Gabriel Hojda.

  * Mon Jul 11 2022 Jan Grulich  - 102.0-2
  - Backport upstream fixes to WebRTC for screensharing on Wayland

  * Tue Jun 28 2022 Martin Stransky - 102.0-1
  - Updated to 102.0
  - Applied patch from 
https://src.fedoraproject.org/rpms/firefox/pull-request/43

  * Mon Jun 27 2022 Martin Stransky - 101.0.1-7
  - Rebuild

  * Fri Jun 17 2022 Martin Stransky - 101.0.1-6
  - Added fix for mozbz#1774271 - Intel/dmabuf export issues.

  * Wed Jun 15 2022 Martin Stransky - 101.0.1-5
  - Added fix for mozbz#1758948 (AV1 VA-API playback shuttering)

  * Tue Jun 14 2022 Martin Stransky - 101.0.1-3
  - Added fixes for mozbz#1773377 and mozbz#1774075

  * Mon Jun 13 2022 Martin Stransky - 101.0.1-2
  - Fix WebGL mem leaks (mzbz#1773968)

  * Thu Jun 09 2022 Martin Stransky - 101.0.1-1
  - Updated to 101.0.1
  - More VA-API sandbox fixes (mzbz#1769182)
  - Fixed OpenH264 decode (rhbz#2094319)

  * Tue Jun 07 2022 Martin Stransky - 101.0-2
  - Enabled VA-API by default (+ added VA-API fixes from upstream)
  - Fixed WebGL performance on NVIDIA drivers (mzbz#1735929)

  * Mon May 30 2022 Martin Stransky - 101.0-1
  - Updated to 101.0

  * Wed May 25 2022 Martin Stransky - 100.0.2-2
  - Added fix for mzbz#1771104

  * Fri May 20 2022 Martin Stransky - 100.0.2-1
  - Updated to 100.0.2

  * Wed May 18 2022 Martin Stransky - 100.0.1-1
  - Updated to 100.0.1

  * Mon May 16 2022 Jan Horak  - 100.0-6
  - Fix spellchecker.dictionary_path of F36+

  * Tue May 10 2022 Jan Horak  - 100.0-5
  - Fix crashes on f36 multimonitor setup and too big profile manager

  * Mon May 09 2022 Martin Stransky - 100.0-4
  - Added fix for mozbz#1767916.

  * Thu May 05 2022 Martin Stransky - 100.0-3

Re: Karma for OpenSSL needed

2022-11-03 Thread Kevin Fenzi
On Thu, Nov 03, 2022 at 12:51:28PM +0100, Vít Ondruch wrote:
> 
> Now who will be motivated enough to at least open the Koji ticket as
> suggested in the other place of this thread? :D
> 
> Actually, for my purposes, it would be much better if there was something
> like `koji download-url --signed openssl`. This would be useful to feed DNF
> directly: `dnf install $(koji download-url --signed openssl)`, because I
> don't like to create some temporary directories.

That could be unexpected if the package is signed by more than one key. 
I guess it would download them all ? But then you have duplicates... 

Not sure the best answer there. 

kevin


signature.asc
Description: PGP 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: Building two conflicting binaries from the same source

2022-11-03 Thread Florian Weimer
* Bojan Smojver via devel:

> Sure, it is easy enough to configure/build repeatedly and stash the
> results into non-conflicting paths of buildroot, but how does one then
> package this in %files sections into exactly the same paths?

See tests/data/SPECS/test-subpackages-pathpostfixes.spec in the RPM
source tree:

| Name:   test
| […]
| %description
| %{summary}.
| 
| %package test2
| RemovePathPostfixes: .foobar
| Summary: Test2.
| %description test2
| […]
| %files
| /bin/hello
| 
| %files test2
| /bin/hello.foobar
| […]

The key enabler is RemovePathPostfixes.

Thanks,
Florian
___
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: Building two conflicting binaries from the same source

2022-11-03 Thread Bojan Smojver via devel
Cool, thank you! I think this is exactly what I was looking for
(unsuccessfully).

-- 
Bojan
___
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: Building two conflicting binaries from the same source

2022-11-03 Thread Artur Frenszek-Iwicki
Hello, Bojan.

The only way I know is to utilise the "RemovePathPostfixes" tag for this, e.g:
> %package gtk3
> RemovePathPostfixes: .gtk3
> 
> %package qt
> RemovePathPostfixes: .qt
> 
> %files gtk3
> %{_bindir}/%{name}.gtk3
> 
> %files qt5
> %{_bindir}/%{name}.qt5
Then, you just need to rename the binaries appropriately during %install.

If you want to read more, I originally learned about it from the following post:
https://www.pixelbeat.org/docs/conflicting-rpms.html

A.FI.
___
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: Building two conflicting binaries from the same source

2022-11-03 Thread Bojan Smojver via devel
PS. I am aware of the alternatives approach, but looking to see whether there 
is something that rpm specs have natively for this.

--
Bojan



4 Nov 2022 7:31:14 am Bojan Smojver :

This may be a trivial question, but my friend Google is not showing me any 
obvious answers, so I will ask here at my own peril.

Say one needs to configure and build the same source with two (or more) 
different sets of options that generate different binary RPMs, but which have 
files in exactly the same place. This is to support different hardware. The end 
result would be mutually conflicting binary packages that users then install 
etc.

Sure, it is easy enough to configure/build repeatedly and stash the results 
into non-conflicting paths of buildroot, but how does one then package this in 
%files sections into exactly the same paths?

If there is an example floating somewhere, that would be very useful.

Thanks,
--
Bojan
___
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: Donate 1 minute of your time to test upgrades from F36 to F37

2022-11-03 Thread Robert Balejik
right, I was running with just "--skip broken"
___
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


Building two conflicting binaries from the same source

2022-11-03 Thread Bojan Smojver via devel
This may be a trivial question, but my friend Google is not showing me any 
obvious answers, so I will ask here at my own peril.

Say one needs to configure and build the same source with two (or more) 
different sets of options that generate different binary RPMs, but which have 
files in exactly the same place. This is to support different hardware. The end 
result would be mutually conflicting binary packages that users then install 
etc.

Sure, it is easy enough to configure/build repeatedly and stash the results 
into non-conflicting paths of buildroot, but how does one then package this in 
%files sections into exactly the same paths?

If there is an example floating somewhere, that would be very useful.

Thanks,
--
Bojan
___
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: PSA: Rawhide KDE users, do not update

2022-11-03 Thread Iñaki Ucar
On Thu, 3 Nov 2022 at 20:34, Gary Buhrmaster  wrote:
>
> On Thu, Nov 3, 2022 at 6:34 PM Adam Williamson
>  wrote:
>
> > Thanks to Aleix Pol, we figured this was due to a missing rebuild of
> > layer-shell-qt , which uses private Qt symbols and so needs rebuilding
> > for each new Qt version. I did that rebuild and KDE's fine again in
> > today's Rawhide, so resume updating. :D
>
> Good catch.
>
> That brings up a question.  Is there any usable
> (automated) tooling/specifications that should/can
> have made the use of private apis be identified
> such that the lack of rebuild does not happen in
> the future for this, or another, package(*)(**)?
> Manual checking of all spec files looking for a
> BR of the Qt private headers sounds prone to
> error.

Packages using Qt private headers usually raise a FTI bug report.
Wasn't this the case with this update?

Iñaki

>
> Thanks.
>
> (*) For the next time, and there will be a next
> time.
>
> (**) Some of the Qt private apis seems somewhat
> stable, but that is only until they are not.
> ___
> 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



-- 
Iñaki Úcar
___
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: PSA: Rawhide KDE users, do not update

2022-11-03 Thread Gary Buhrmaster
On Thu, Nov 3, 2022 at 6:34 PM Adam Williamson
 wrote:

> Thanks to Aleix Pol, we figured this was due to a missing rebuild of
> layer-shell-qt , which uses private Qt symbols and so needs rebuilding
> for each new Qt version. I did that rebuild and KDE's fine again in
> today's Rawhide, so resume updating. :D

Good catch.

That brings up a question.  Is there any usable
(automated) tooling/specifications that should/can
have made the use of private apis be identified
such that the lack of rebuild does not happen in
the future for this, or another, package(*)(**)?
Manual checking of all spec files looking for a
BR of the Qt private headers sounds prone to
error.

Thanks.

(*) For the next time, and there will be a next
time.

(**) Some of the Qt private apis seems somewhat
stable, but that is only until they are not.
___
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: Announcing spdlog soversion bump

2022-11-03 Thread Vitaly Zaitsev via devel

On 03/11/2022 08:51, Vitaly Zaitsev wrote:
I will try building all these packages in a COPR repository and then use 
my PP rights to rebuild them in a side tag for Rawhide and F37.


Rawhide builds completed. 2 packages failed to build for unrelated reasons:

- bear (1 test failed on s390x)
- gerbera (cmake can't find systemd)

FTBFS tickets created.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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


[rpms/perl-WWW-Splunk] PR #1: Package tests and update license to SPDX format

2022-11-03 Thread Michal Josef Špaček

mspacek merged a pull-request against the project: `perl-WWW-Splunk` that you 
are following.

Merged pull-request:

``
Package tests and update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-WWW-Splunk/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2137926] perl-Moo needs to provide "perl(Moo::_Utils)"

2022-11-03 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137926



--- Comment #3 from pj  ---
Thank you for pointing out the private module part. I'm not a perl programmer,
just a sysadmin trying to rpmbuild all of the perl modules the dev's need.
It does look like the Fedora 36 src.rpm of perl-MooX-TypeTiny does produce the
correct rpm package dependencies (not requiring the Moo::_Utils).

So, if the normal procedure is to not include these private, then please close.
I can proceed using the Fedora src.rpm instead of getting the latest via
cpanspec (which is the same ATM).
Thank you for your help on this!


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137926
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: PSA: Rawhide KDE users, do not update

2022-11-03 Thread Adam Williamson
On Wed, 2022-11-02 at 09:51 -0700, Adam Williamson wrote:
> Hey, folks. Just a heads up: today's Rawhide has a new Qt which seems
> to make SDDM crash on startup, so the system boots to a black screen
> and you can't log in. So, updating may not be a great idea!
> 
> I've filed this as https://bugzilla.redhat.com/show_bug.cgi?id=2139465
> and https://github.com/sddm/sddm/issues/1608 . Unfortunately haven't
> been able to get a usable backtrace yet.

Thanks to Aleix Pol, we figured this was due to a missing rebuild of
layer-shell-qt , which uses private Qt symbols and so needs rebuilding
for each new Qt version. I did that rebuild and KDE's fine again in
today's Rawhide, so resume updating. :D
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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


[Bug 2137926] perl-Moo needs to provide "perl(Moo::_Utils)"

2022-11-03 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2137926



--- Comment #2 from pj  ---
Sorry, I had missed the question originally.
This seemed to have happened as part of a set of cpanspec perl package builds.
Somehow perl-MooX-TypeTiny is requiring the "Moo::_Utils". It was part of a
mass build for RHEL/AlmaLinux 9.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2137926
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-WWW-Splunk] PR #1: Package tests and update license to SPDX format

2022-11-03 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-WWW-Splunk` that 
you are following:
``
Package tests and update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-WWW-Splunk/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2139888] New: perl-DBD-SQLite-1.72 is available

2022-11-03 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2139888

Bug ID: 2139888
   Summary: perl-DBD-SQLite-1.72 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBD-SQLite
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
ka...@ucw.cz, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org, spo...@gmail.com,
st...@silug.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.72
Upstream release that is considered latest: 1.72
Current version/release in rawhide: 1.70-5.fc37
URL: http://search.cpan.org/dist/DBD-SQLite/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2810/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-DBD-SQLite


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139888
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Deprecating intents in Modularity

2022-11-03 Thread Matthew Miller
On Wed, Nov 02, 2022 at 04:45:41PM +0100, Petr Pisar wrote:
> Hello module maintainers,
> 
> do you know intents
> ?
> I believe you don't. Do you use intents? I hope you don't.
> 
> In modularity, default streams and default profiles can be parametrized by
> a system role (purpose, variant, spin). Modularity calls it an "intent".
> 
> Theoretically, if you install Fedora Workstation and then install a postgresql
> module, client libraries or tools for PostgreSQL could be installed. While
> installing the same module on a Server spin would instead install PostgreSQL
> server.

Or, for example, if we had a "personal productivity apps" module, and you
had KDE Plasma installed, you'd get a KDE-flavored set of these apps, while
if you had GNOME Shell you'd get gtk ones. :)


That said... obviously we didn't get there. So I am fine with dropping this
feature.


-- 
Matthew Miller

Fedora Project Leader
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Sergey Mende
> On Thu, 3 Nov 2022 at 12:24, Gary Buhrmaster  wrote:
...
> ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_mandir}/\*' *spec | wc -l
> 417

I think that for `%{_mandir}` each subdir should be accounted separately:

```
for i in 1 2 3 4 5 6 7; do echo "%{_mandir}/man$i/* $(egrep 
'^%{_mandir}/man'$i'/\*' *.spec|wc -l)"; done
%{_mandir}/man1/* 896
%{_mandir}/man2/* 3
%{_mandir}/man3/* 2405
%{_mandir}/man4/* 4
%{_mandir}/man5/* 108
%{_mandir}/man6/* 25
%{_mandir}/man7/* 47
```

Sergey 
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Gary Buhrmaster
On Thu, Nov 3, 2022 at 4:07 PM Stephen Smoogen  wrote:

> At the moment the biggest set of packages that need cleanup will be perl, 
> golang and then about a couple hundred library rpms.

I would think that the man api definitions may
be the most interesting for some libraries
(many files, sometimes un-glob-able by any
sort of prefix selection even if that is considered
to be allowed).
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Stephen Smoogen
On Thu, 3 Nov 2022 at 12:24, Gary Buhrmaster 
wrote:

> On Thu, Nov 3, 2022 at 3:57 PM Adam Williamson
>  wrote:
>
> > there, I did it for free. Took one minute.
>
> Clearly it should be submitted as a PR to the kernel package.
>
> And another for the glibc package (that
> one likely will take more than a minute).
>
>
So glibc will be hard one because it has sections like:
```
 %files -f langpack-]]..lang..[[.filelist langpack-]]..lang..[[
]]))
end

for i = 1, #locales do
   lang_package(locales[i])
end
}
```
and
```
%files -f devel.filelist devel
%if %{glibc_autorequires}
%attr(0755,root,root) %{_rpmconfigdir}/glibc.req
%{_fileattrsdir}/glibc.attr
%endif
```

Looking through the spec files used for rawhide today.. there are 1242
packages which use %{bindir}/* with the bulk of them in golang and perl.
```
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_includedir}/\*' *spec | wc
-l
487
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_docdir}/\*' *spec | wc -l
6
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_mandir}/\*' *spec | wc -l
417
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_bindir}/\*' *spec | wc -l
1242
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_datadir}/\*' *spec | wc -l
3
```

the two small sets are like
```
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_datadir}/\*' *spec
gawk.spec:%{_datadir}/*awk
gnome-pomodoro.spec:%{_datadir}/*/org.gnome.Pomodoro.appdata.xml
htmlcxx.spec:%{_datadir}/*
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_docdir}/\*' *spec
acpica-tools.spec:%{_docdir}/*/*
assimp.spec:%{_docdir}/*
freecell-solver.spec:%{_docdir}/*
prboom-plus.spec:%{_docdir}/*
sblim-sfcc.spec:%{_docdir}/*
vmod-querystring.spec:%{_docdir}/*
```

I am guessing the pomodoro would be ok and the others should be easyfix.

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Adam Williamson
On Thu, 2022-11-03 at 17:07 +0100, Vitaly Zaitsev via devel wrote:
> On 03/11/2022 17:01, Gary Buhrmaster wrote:
> > As I recall(*), there are spec files that just
> > find the various installed files (categorized
> > as needed), and then use the -f option
> > on the %files section.
> 
> IMO, such behavior should be strictly prohibited.

I would say the guidelines assume good faith in general, so it should
be considered as kind of implicit that it's not OK to do weird things
whose sole intent is to get around the strict wording of a guideline
but achieve the effect the guideline is trying to avoid.

Otherwise the guidelines will start to look like criminal statutes and
be about as long, which I don't think anyone wants.

It has already been noted this is a SHOULD guideline, not a MUST
guideline, which means it's not a hard requirement in any case, and if
there are cases where a wildcard is clearly the least worst choice it's
probably OK.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Daniel P . Berrangé
On Thu, Nov 03, 2022 at 04:01:58PM +, Gary Buhrmaster wrote:
> On Thu, Nov 3, 2022 at 12:12 PM Stephen Smoogen  wrote:
> 
> > Or they will just do what I used to do long ago and just do a temp spec 
> > file with some sort of `%files *` and then rpm -ql and then `rpm -ql | sed` 
> > and replace the data in the pushed spec with the list. Nothing is caught 
> > because few people have time for the several hundred packages they are 
> > maintaining.
> 
> As I recall(*), there are spec files that just
> find the various installed files (categorized
> as needed), and then use the -f option
> on the %files section.  Which, technically,
> meets the requirements, while not dealing
> with the intent at all.  I think this is really
> a question of scale.  For smaller packages
> with a small number of expected files,
> listing them explicitly is going to be a
> smaller burden to add or maintain, but for
> larger packages (arguably exactly the
> ones that are more likely to "stomp" on
> other files and you want to catch changes
> for), the work is likely much higher (to the
> point that one adds in automation to hide
> the work).

I don't think that the scale question is a big factor here
because this is a one-time hit when creating the spec. If a
package install 1000 files into %{_bindir} or %{_includedir}
by all means use a script to automate the filling of %files
without wildcards, when first authoring the spec file.

On subsequent updates to new releases, the projects are not going
to be adding/removing huge numbers of files in these directories.
You'll be looking out for a small number of changes, just like any
other package regardless of scale.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Vitaly Zaitsev via devel

On 03/11/2022 17:01, Gary Buhrmaster wrote:

As I recall(*), there are spec files that just
find the various installed files (categorized
as needed), and then use the -f option
on the %files section.


IMO, such behavior should be strictly prohibited.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Stephen Smoogen
On Thu, 3 Nov 2022 at 11:26, Maxwell G via devel <
devel@lists.fedoraproject.org> wrote:

> On Thu Nov 3, 2022 at 06:50 +0100, Kevin Kofler via devel wrote:
> > When will this silliness ever stop? It just does not make sense to
> > explicitly list every single file in the RPM. Wildcards are often the
> only
> > reasonable way.
>
> Nobody is saying that you have to list every single file in the package
> or that e.g. adding `%{_datadir}/%{name}/` to %files is prohibited. It
> is simply not allowed to glob absolutely everything under a shared
> directory. For instance, ansible-core installs 11 different binaries
> into %{_bindir} that all start with `ansible` that would be tedious to
> list out manually. Instead of globing all of %{_bindir} with
> `%{_bindir}/*, I could add `%{_bindir}/ansible*` which complies with
> this guideline and is just as simple.
>
>
I read the section twice before posting, and because there were no examples
countering it and the text for why it was done said

`The most common mistake this rule prevents is upstream adding new commands
in %{_bindir}/*.`

I came to the conclusion that even `%{bindir}/ansible*` would be against
this as you would still miss
a) if ansible-foobaz had been added to the package when it had not been
there before
b) if ansible-foobaz was in a different package and you have an
unintentional conflict.

In either case, the only fix would be to explicitly list out every filename
each time so you were aware that things had been added or removed. I am not
sure how to better word this to escape this confusion but having a working
counterexample of saying `%{bindir}/ansible*` is ok would probably help.

At the moment the biggest set of packages that need cleanup will be perl,
golang and then about a couple hundred library rpms.

-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Gary Buhrmaster
On Thu, Nov 3, 2022 at 3:57 PM Adam Williamson
 wrote:

> there, I did it for free. Took one minute.

Clearly it should be submitted as a PR to the kernel package.

And another for the glibc package (that
one likely will take more than a minute).
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Gary Buhrmaster
On Thu, Nov 3, 2022 at 12:12 PM Stephen Smoogen  wrote:

> Or they will just do what I used to do long ago and just do a temp spec file 
> with some sort of `%files *` and then rpm -ql and then `rpm -ql | sed` and 
> replace the data in the pushed spec with the list. Nothing is caught because 
> few people have time for the several hundred packages they are maintaining.

As I recall(*), there are spec files that just
find the various installed files (categorized
as needed), and then use the -f option
on the %files section.  Which, technically,
meets the requirements, while not dealing
with the intent at all.  I think this is really
a question of scale.  For smaller packages
with a small number of expected files,
listing them explicitly is going to be a
smaller burden to add or maintain, but for
larger packages (arguably exactly the
ones that are more likely to "stomp" on
other files and you want to catch changes
for), the work is likely much higher (to the
point that one adds in automation to hide
the work).


(*) I think glibc is an example, but it
has been some time since I looked.
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Adam Williamson
On Thu, 2022-11-03 at 15:31 +, Gary Buhrmaster wrote:
> On Thu, Nov 3, 2022 at 12:10 PM Ian McInerney via devel
>  wrote:
> 
> > But the packaging guidelines already mentioned not globbing the soname part 
> > of the files, so this change makes no difference to that use case. 
> > Extending the no-globbing rule to other directories like datadir seems very 
> > excessive. Why should we have to list all files a package wants to ship as 
> > its data?
> 
> The soname always (mostly) made sense since
> it addressed one of the common issues of soname
> bumps that were often missed that could impact
> other packages (we still regularly get "unannounced
> soname bump" emails, which suggests that that
> package did not have an explicit soname spec;
> I would hope one of the fixes in that case updated
> the spec file to address the soname glob).  Sure,
> some packagers are very good about the entire
> soname bump issue, but I believe that adding the
> suspenders to the belt was not overly onerous.
> 
> On the other hand, executable and include files
> are going to be interesting.  I, for one, look forward
> to seeing the response(s) from someone such as
> the kernel packager who now SHOULD explicitly
> identify all the include files in the kernel-headers
> package (to pick on an obvious example).

Again, this is a misunderstanding of what the rule says. It does not at
all mean you have to list every file.

The kernel could probably be considered an exception, but even there,
if it were to comply with the rule, it would only need this:

/usr/include/asm*
/usr/include/drm
/usr/include/linux
/usr/include/misc
/usr/include/mtd
/usr/include/rdma
/usr/include/scsi
/usr/include/sound
/usr/include/video
/usr/include/xen

there, I did it for free. Took one minute.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Adam Williamson
On Thu, 2022-11-03 at 12:08 +, Ian McInerney via devel wrote:
> On Thu, Nov 3, 2022 at 12:02 PM Michael J Gruber 
> wrote:
> 
> > While it is annoying to spell out each file it does catch package changes
> > which might go unnoticed otherwise. In particular, we've had a few
> > unannounced soname changes and such lately. [Disclaimer: I have not checked
> > whether the maintainer ignored the build failure for an explicit soname or
> > got trapped by a wildcard in these cases.]
> > 
> 
> But the packaging guidelines already mentioned not globbing the soname part
> of the files, so this change makes no difference to that use case.
> Extending the no-globbing rule to other directories like datadir seems very
> excessive. Why should we have to list all files a package wants to ship as
> its data?

You don't. You can use less general wildcards. Just don't wildcard
absolutely everything in the directory. If the project is putting
dozens of files that don't contain something obviously usable for a
more specific wildcard - like the project's name - *directly* into one
of those directories (the rule doesn't forbid you including an entire
subdirectory, note) - that in itself is a bad idea that you as the
packager ought to be aware of and keep an eye on to make sure it
doesn't unnecessarily conflict with other packages.

The rule comes with an explanation:

"This rule serves as a check against common mistakes
which are otherwise hard to detect.
It does limit some possibilities for automation.

The most common mistake this rule prevents is upstream adding new
commands in `+%{_bindir}/*+`.
You should always check such changes for
https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_common_conflicting_files_cases_and_solutions
,
and keep the list of such files explicit and auditable."

I agree it should have been announced, though.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
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: [Fedocal] Reminder meeting : ELN SIG

2022-11-03 Thread Stephen Gallagher
On Thu, Nov 3, 2022 at 8:09 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2022-11-04 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:

Current status of aarch64 and ppc64le with debug kernels.
ELN Process Documentation

___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Gary Buhrmaster
On Thu, Nov 3, 2022 at 12:10 PM Ian McInerney via devel
 wrote:

> But the packaging guidelines already mentioned not globbing the soname part 
> of the files, so this change makes no difference to that use case. Extending 
> the no-globbing rule to other directories like datadir seems very excessive. 
> Why should we have to list all files a package wants to ship as its data?

The soname always (mostly) made sense since
it addressed one of the common issues of soname
bumps that were often missed that could impact
other packages (we still regularly get "unannounced
soname bump" emails, which suggests that that
package did not have an explicit soname spec;
I would hope one of the fixes in that case updated
the spec file to address the soname glob).  Sure,
some packagers are very good about the entire
soname bump issue, but I believe that adding the
suspenders to the belt was not overly onerous.

On the other hand, executable and include files
are going to be interesting.  I, for one, look forward
to seeing the response(s) from someone such as
the kernel packager who now SHOULD explicitly
identify all the include files in the kernel-headers
package (to pick on an obvious example).
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Maxwell G via devel
On Thu Nov 3, 2022 at 06:50 +0100, Kevin Kofler via devel wrote:
> When will this silliness ever stop? It just does not make sense to
> explicitly list every single file in the RPM. Wildcards are often the only
> reasonable way.

Nobody is saying that you have to list every single file in the package
or that e.g. adding `%{_datadir}/%{name}/` to %files is prohibited. It
is simply not allowed to glob absolutely everything under a shared
directory. For instance, ansible-core installs 11 different binaries
into %{_bindir} that all start with `ansible` that would be tedious to
list out manually. Instead of globing all of %{_bindir} with
`%{_bindir}/*, I could add `%{_bindir}/ansible*` which complies with
this guideline and is just as simple.

I think this is a sensible rule as it prevents conflicts and other
issues from popping up on updates when a package's build scripts start
installing new files. When reviewing Go packages, I've caught multiple
issues with `%{_bindir}/*` globs that hide conflicting files and/or
test/utility binaries that shouldn't be shipped to begin with.
Unfortunately, go2rpm generates specfiles with these globs by default.

FWIW, this is a SHOULD guideline not a MUST guideline, but I don't see a
case where such broad globs are justifiable.

As for the other complaint, I subscribe to the FPC issue tracker[1] to
to keep up with guidelines changes. There's also the packaging list, but
not a lot of active discussion happens there. I agree that it would be
beneficial to make changes more visible.

[1]: https://pagure.io/packaging-committee


--
Maxwell G (@gotmax23)
Pronouns: He/Him/His


signature.asc
Description: PGP 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


[Bug 2139824] perl-Sys-Virt-8.9.0 is available

2022-11-03 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2139824

Jitka Plesnikova  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED
 CC|berra...@redhat.com,|
   |crobi...@redhat.com,|
   |jples...@redhat.com,|
   |st...@silug.org |




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139824
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2139824] New: perl-Sys-Virt-8.9.0 is available

2022-11-03 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2139824

Bug ID: 2139824
   Summary: perl-Sys-Virt-8.9.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Sys-Virt
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com, crobi...@redhat.com,
jples...@redhat.com,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 8.9.0
Upstream release that is considered latest: 8.9.0
Current version/release in rawhide: 8.8.0-1.fc38
URL: http://search.cpan.org/dist/Sys-Virt/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/3355/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Sys-Virt


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139824
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-XML-Fast] PR #1: Package tests and update license to SPDX format

2022-11-03 Thread Michal Josef Špaček

mspacek merged a pull-request against the project: `perl-XML-Fast` that you are 
following.

Merged pull-request:

``
Package tests and update license to SPDX format
``

https://src.fedoraproject.org/rpms/perl-XML-Fast/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-XML-Fast] PR #1: Package tests and update license to SPDX format

2022-11-03 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-XML-Fast` that you 
are following:
``
Package tests and update license to SPDX format
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-XML-Fast/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Fedora rawhide compose report: 20221103.n.0 changes

2022-11-03 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20221102.n.0
NEW: Fedora-Rawhide-20221103.n.0

= SUMMARY =
Added images:1
Dropped images:  0
Added packages:  3
Dropped packages:5
Upgraded packages:   74
Downgraded packages: 0

Size of added packages:  17.86 MiB
Size of dropped packages:5.29 MiB
Size of upgraded packages:   3.07 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -3.71 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20221103.n.0.ppc64le.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: dnf5-5.0.0-2~pre.fc38
Summary: Command-line package manager
RPMs:dnf5 dnf5-plugins dnf5daemon-client dnf5daemon-server libdnf5 
libdnf5-cli libdnf5-cli-devel libdnf5-devel libdnf5-plugin-actions perl-libdnf5 
perl-libdnf5-cli python3-libdnf5 python3-libdnf5-cli 
python3-libdnf5-python-plugins-loader ruby-libdnf5 ruby-libdnf5-cli
Size:17.52 MiB

Package: rust-strength_reduce-0.2.3-1.fc38
Summary: Faster integer division and modulus operations
RPMs:rust-strength_reduce+default-devel rust-strength_reduce-devel
Size:31.96 KiB

Package: rust-termwiz-0.17.1-2.fc38
Summary: Terminal Wizardry for Unix and Windows
RPMs:rust-termwiz+cassowary-devel rust-termwiz+default-devel 
rust-termwiz+docs-devel rust-termwiz+fnv-devel rust-termwiz+image-devel 
rust-termwiz+serde-devel rust-termwiz+use_image-devel 
rust-termwiz+use_serde-devel rust-termwiz+widgets-devel rust-termwiz-devel
Size:318.39 KiB


= DROPPED PACKAGES =
Package: golang-github-beevik-etree-1.1.0-7.fc37
Summary: Parse and generate XML easily in go
RPMs:golang-github-beevik-etree-devel
Size:33.62 KiB

Package: golang-github-containerd-cri-1:1.19.0-6.20210307gitaa2d5a9.fc35
Summary: Containerd Plugin for Kubernetes Container Runtime Interface
RPMs:golang-github-containerd-cri-devel
Size:546.91 KiB

Package: golang-github-magefile-mage-1.11.0-7.fc37
Summary: A Make/rake-like dev tool using Go
RPMs:golang-github-magefile-mage golang-github-magefile-mage-devel
Size:4.67 MiB

Package: golang-github-timberio-datemath-0.1.0-5.20200710git85899cb.fc37
Summary: Go library for parsing Elasticsearch datemath expressions
RPMs:golang-github-timberio-datemath-devel
Size:21.70 KiB

Package: golang-github-ua-parser-uap-0-8.20200803gite1c09f1.fc37
Summary: Go implementation of ua-parser
RPMs:golang-github-ua-parser-uap-devel
Size:40.56 KiB


= UPGRADED PACKAGES =
Package:  NetworkManager-1:1.41.4-1.fc38
Old package:  NetworkManager-1:1.41.3-1.fc38
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-initscripts-ifcfg-rh NetworkManager-initscripts-updown 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 24.90 MiB
Size change:  285.55 KiB
Changelog:
  * Wed Nov 02 2022 Wen Liang  - 1:1.41.4-1
  - Upgrade to 1.41.4 release


Package:  R-4.2.2-1.fc38
Old package:  R-4.2.1-5.fc38
Summary:  A language for data analysis and graphics
RPMs: R R-core R-core-devel R-devel R-java R-java-devel libRmath 
libRmath-devel libRmath-static
Size: 312.52 MiB
Size change:  -16.69 MiB
Changelog:
  * Mon Oct 31 2022 I??aki ??car  - 4.2.2-1
  - Update to 4.2.2
  - Run new compact-pdf target
  - Remove obsolete MAKEINFO and texinfo hack
  - Re-enable tests


Package:  ansible-7.0.0~a2-1.fc38
Old package:  ansible-6.5.0-1.fc38
Summary:  Curated set of Ansible collections included in addition to 
ansible-core
RPMs: ansible
Size: 43.54 MiB
Size change:  -4.10 MiB
Changelog:
  * Fri Oct 28 2022 Maxwell G  - 7.0.0~a2-1
  - Update to 7.0.0~a2.


Package:  ansible-collection-community-docker-3.2.0-2.fc38
Old package:  ansible-collection-community-docker-3.1.0-1.fc38
Summary:  Ansible modules and plugins for working with Docker
RPMs: ansible-collection-community-docker
Size: 215.02 KiB
Size change:  732 B
Changelog:
  * Wed Nov 02 2022 Maxwell G  - 3.2.0-1
  - Update to 3.2.0. Fixes rhbz#2139344.

  * Thu Nov 03 2022 Maxwell G  - 3.2.0-2
  - Remove unexpanded macros from %description
  - Handle .reuse/dep5


Package:  ansible-core-2.14.0~rc2-1.fc38
Old package:  ansible-core-2.13.5-1.fc38
Summary:  A radically simple IT automation system
RPMs: ansible-core ansible-core-doc
Size: 5.27 MiB
Size change:  158.91 KiB
Changelog:
  * Fri Oct 28 2022 Maxwell G  - 2.14.0~rc1-1
  - Update to 2.14.0~rc1.

  * Wed Nov 02 2022 Maxwell G  - 2.14.0~rc2-1
  - Update to 2.14.0~rc2.


Package:  antlr4-project

Re: Silent changes in Packaging Guidelines

2022-11-03 Thread Stephen Smoogen
On Thu, 3 Nov 2022 at 08:02, Michael J Gruber  wrote:

> While it is annoying to spell out each file it does catch package changes
> which might go unnoticed otherwise. In particular, we've had a few
> unannounced soname changes and such lately. [Disclaimer: I have not checked
> whether the maintainer ignored the build failure for an explicit soname or
> got trapped by a wildcard in these cases.]
>
>
Or they will just do what I used to do long ago and just do a temp spec
file with some sort of `%files *` and then rpm -ql and then `rpm -ql | sed`
and replace the data in the pushed spec with the list. Nothing is caught
because few people have time for the several hundred packages they are
maintaining.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Ian McInerney via devel
On Thu, Nov 3, 2022 at 12:02 PM Michael J Gruber 
wrote:

> While it is annoying to spell out each file it does catch package changes
> which might go unnoticed otherwise. In particular, we've had a few
> unannounced soname changes and such lately. [Disclaimer: I have not checked
> whether the maintainer ignored the build failure for an explicit soname or
> got trapped by a wildcard in these cases.]
>

But the packaging guidelines already mentioned not globbing the soname part
of the files, so this change makes no difference to that use case.
Extending the no-globbing rule to other directories like datadir seems very
excessive. Why should we have to list all files a package wants to ship as
its data?

-Ian


>
> We could probably live better with wildcards if proper rpmdiff-tools were
> part of the workflow and of gating or such. Those would be the right tool
> for the job.
> ___
> 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
>
___
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: Silent changes in Packaging Guidelines

2022-11-03 Thread Michael J Gruber
While it is annoying to spell out each file it does catch package changes which 
might go unnoticed otherwise. In particular, we've had a few unannounced soname 
changes and such lately. [Disclaimer: I have not checked whether the maintainer 
ignored the build failure for an explicit soname or got trapped by a wildcard 
in these cases.]

We could probably live better with wildcards if proper rpmdiff-tools were part 
of the workflow and of gating or such. Those would be the right tool for the 
job.
___
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: How to fix RPM ARCH not defined?

2022-11-03 Thread Vít Ondruch
Just FTR, the ticket is a bit inconsistent. It is reported against 
EPEL7, while it seems the issues are with `/usr/lib64/grass82` which is 
not available in EPEL7 as far as I can tell.



Vít


Dne 02. 11. 22 v 21:43 Markus Neteler napsal(a):

Hi,

I am one of the maintainers of the GRASS GIS package (also a core
developer) and currently stuck with this bug report:

RPM ARCH not defined
https://bugzilla.redhat.com/show_bug.cgi?id=2138373

I was able to reproduce it in a F37 docker container but have no clue
how to address this problem.
The dirty hack of settings these env variables "solves" it but there
must be a real solution:

export RPM_ARCH=bla
export RPM_PACKAGE_RELEASE=bla
export RPM_PACKAGE_VERSION=bla
export RPM_PACKAGE_NAME=bla

Hints welcome!

Thanks,
Markus



OpenPGP_signature
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


[Fedocal] Reminder meeting : ELN SIG

2022-11-03 Thread sgallagh
Dear all,

You are kindly invited to the meeting:
   ELN SIG on 2022-11-04 from 12:00:00 to 13:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:



Source: https://calendar.fedoraproject.org//meeting/10133/

___
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: Karma for OpenSSL needed

2022-11-03 Thread Vít Ondruch


Dne 02. 11. 22 v 20:28 Josh Stone napsal(a):

On 11/1/22 3:51 PM, Kevin Fenzi wrote:

On Tue, Nov 01, 2022 at 02:55:34PM -0700, Josh Stone wrote:

On 11/1/22 11:16 AM, Neal Gompa wrote:

That said, the packages *are* signed in Koji, because as soon as it's
submitted to Bodhi, the packages are signed in-place in Koji.

Is that really in-place? Bodhi says these are signed, but when I
download from koji, "rpm -qip" still shows "Signature: (none)".

If you download the direct build links you get unsigned copies.

If you use something like:

koji download-build --key=5323552a openssl-3.0.5-2.fc37

you get builds signed with the f37 key.

Or you can look directly at:
https://kojipkgs.fedoraproject.org/packages/openssl/3.0.5/3.fc37/data/signed/5323552a/

It would be great to have that linked from Bodhi, perhaps on the Builds
tab on the "Build signed" key icon for each package.



Now who will be motivated enough to at least open the Koji ticket as 
suggested in the other place of this thread? :D


Actually, for my purposes, it would be much better if there was 
something like `koji download-url --signed openssl`. This would be 
useful to feed DNF directly: `dnf install $(koji download-url --signed 
openssl)`, because I don't like to create some temporary directories.



Vít



OpenPGP_signature
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


[rpms/perl-XML-Spice] PR #1: Package tests and update license format to SPDX

2022-11-03 Thread Michal Josef Špaček

mspacek merged a pull-request against the project: `perl-XML-Spice` that you 
are following.

Merged pull-request:

``
Package tests and update license format to SPDX
``

https://src.fedoraproject.org/rpms/perl-XML-Spice/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[rpms/perl-XML-Spice] PR #1: Package tests and update license format to SPDX

2022-11-03 Thread Michal Josef Špaček

mspacek opened a new pull-request against the project: `perl-XML-Spice` that 
you are following:
``
Package tests and update license format to SPDX
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-XML-Spice/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Silent changes in Packaging Guidelines

2022-11-03 Thread Stephen Smoogen
On Wed, 2 Nov 2022 at 05:04, Petr Pisar  wrote:

> It used to be a good practice to announce changes in Packaging Guidelines
>  here on this
> list. The forkflow was that Fedora Packaging Committee accepted a change on
> it's meeting and then announced it in their meeting notes posted here. This
> workflow allowed packagers to notice the changes and apply them to their
> packages.
>
>



> +=== Explicit lists
> +
> +Packagers *SHOULD NOT* simply glob everything under a shared
> directory.
> +
> +In particular, the following *SHOULD NOT* be used in `+%files+`:
> +
> +* `+%{_bindir}/*+`
> +* `+%{_datadir}/*+`
> +* `+%{_includedir}/*+`
> +* `+%{_mandir}/*+`
> +* `+%{_docdir}/*+`
>
> To my surprise the first time when I get known to this new rule was today
> in a review of my new package.
>
>
Ugh changes like that really need a bit more open discussion and they need
to be announced here. What is the problem trying to be solved by this? Does
this solution actually solve that problem or band-aid it?

That said, it isn't like I as a packager have been following the packaging
committee enough to actually know what is going on. I have just taken it
for granted that they would just do what I felt was the right thing without
telling them that. Nor have I run for the packaging committee or spent time
dealing with the crap that trying to deal with N factorial combinations of
languages requires.

So what is the right way to deal with this? Have more people join the
packaging list and start asking questions?

On this rule, I am not sure how large packages are going to work. My guess
would be that some packager will come up with a script which just does the
glob, and then outputs the data in a list which is then sed back to be
`%{FOOdir}/blah1 %{FOOdir}/blah2 etc` And the problem trying to be solved
of stuff getting added in without review.. will just go out the door.


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
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: Donate 1 minute of your time to test upgrades from F36 to F37

2022-11-03 Thread Federico Pellegrin
Error:
 Problem 1: package webkit2gtk3-2.38.1-1.fc36.x86_64 requires
libicui18n.so.69()(64bit), but none of the providers can be installed
  - package webkit2gtk3-2.38.1-1.fc36.x86_64 requires
libicuuc.so.69()(64bit), but none of the providers can be installed
  - libicu-69.1-6.fc36.x86_64 does not belong to a distupgrade repository
  - problem with installed package webkit2gtk3-2.38.1-1.fc36.x86_64
 Problem 2: package boost-regex-1.78.0-9.fc37.x86_64 requires
libicui18n.so.71()(64bit), but none of the providers can be installed
  - package boost-regex-1.78.0-9.fc37.x86_64 requires
libicuuc.so.71()(64bit), but none of the providers can be installed
  - package boost-regex-1.78.0-9.fc37.x86_64 requires
libicudata.so.71()(64bit), but none of the providers can be installed
  - cannot install both libicu-71.1-2.fc37.x86_64 and
libicu-69.1-6.fc36.x86_64
  - problem with installed package boost-regex-1.76.0-12.fc36.x86_64
  - package webkit2gtk3-jsc-2.38.1-1.fc36.x86_64 requires
libicui18n.so.69()(64bit), but none of the providers can be installed
  - package webkit2gtk3-jsc-2.38.1-1.fc36.x86_64 requires
libicuuc.so.69()(64bit), but none of the providers can be installed
  - boost-regex-1.76.0-12.fc36.x86_64 does not belong to a distupgrade
repository
  - problem with installed package webkit2gtk3-jsc-2.38.1-1.fc36.x86_64
(try to add '--allowerasing' to command line to replace conflicting
packages or '--skip-broken' to skip uninstallable packages)

Seemingly all fine after --allowerasing.

Cheers,


Il giorno gio 3 nov 2022 alle ore 10:33 Robert Balejik 
ha scritto:

>  Problem 1: package gala-libs-6.3.1-3.fc36.x86_64 requires
> libmutter-10.so.0()(64bit), but none of the providers can be installed
>   - package gala-libs-6.3.1-3.fc36.x86_64 requires
> libmutter-clutter-10.so.0()(64bit), but none of the providers can be
> installed
>   - mutter-42.5-3.fc36.x86_64 does not belong to a distupgrade repository
>   - problem with installed package gala-libs-6.3.1-3.fc36.x86_64
>  Problem 2: package gnome-screensaver-3.6.1-27.fc32.x86_64 requires
> libgnome-desktop-3.so.19()(64bit), but none of the providers can be
> installed
>   - gnome-desktop3-42.4-1.fc36.x86_64 does not belong to a distupgrade
> repository
>   - problem with installed package gnome-screensaver-3.6.1-27.fc32.x86_64
>  Problem 3: package horst-3.0-6.fc23.x86_64 requires
> libncurses.so.5()(64bit), but none of the providers can be installed
>   - package horst-3.0-6.fc23.x86_64 requires libtinfo.so.5()(64bit), but
> none of the providers can be installed
>   - ncurses-compat-libs-6.2-9.20210508.fc36.x86_64 does not belong to a
> distupgrade repository
>   - problem with installed package horst-3.0-6.fc23.x86_64
>  Problem 4: package rpmfusion-nonfree-release-36-1.noarch requires
> system-release(36), but none of the providers can be installed
>   - fedora-release-workstation-36-20.noarch does not belong to a
> distupgrade repository
>   - fedora-release-36-20.noarch does not belong to a distupgrade repository
>   - problem with installed package rpmfusion-nonfree-release-36-1.noarch
>  Problem 5: problem with installed package
> switchboard-plug-tweaks-1.0.3-3.fc36.x86_64
>   - package switchboard-plug-tweaks-1.0.4-2.fc37.x86_64 requires
> switchboard(x86-64), but none of the providers can be installed
>   - switchboard-plug-tweaks-1.0.3-3.fc36.x86_64 does not belong to a
> distupgrade repository
>   - switchboard-6.0.2-1.fc36.x86_64 does not belong to a distupgrade
> repository
>  Problem 6: package rpmfusion-nonfree-release-36-1.noarch requires
> system-release(36), but none of the providers can be installed
>   - package fedora-release-36-20.noarch requires fedora-release-common =
> 36-20, but none of the providers can be installed
>   - package fedora-release-workstation-36-20.noarch requires
> fedora-release-common = 36-20, but none of the providers can be installed
>   - package fedy-4.8.0-1.fc28.noarch requires rpmfusion-nonfree-release,
> but none of the providers can be installed
>   - fedora-release-common-36-20.noarch does not belong to a distupgrade
> repository
>   - problem with installed package fedy-4.8.0-1.fc28.noarch
> ___
> 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
>
___
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: 

[Bug 2139510] perl-URI-5.17 is available

2022-11-03 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2139510



--- Comment #1 from Fedora Update System  ---
FEDORA-2022-c98b928028 has been submitted as an update to Fedora 37.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-c98b928028


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139510
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Donate 1 minute of your time to test upgrades from F36 to F37

2022-11-03 Thread Robert Balejik
 Problem 1: package gala-libs-6.3.1-3.fc36.x86_64 requires 
libmutter-10.so.0()(64bit), but none of the providers can be installed
  - package gala-libs-6.3.1-3.fc36.x86_64 requires 
libmutter-clutter-10.so.0()(64bit), but none of the providers can be installed
  - mutter-42.5-3.fc36.x86_64 does not belong to a distupgrade repository
  - problem with installed package gala-libs-6.3.1-3.fc36.x86_64
 Problem 2: package gnome-screensaver-3.6.1-27.fc32.x86_64 requires 
libgnome-desktop-3.so.19()(64bit), but none of the providers can be installed
  - gnome-desktop3-42.4-1.fc36.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package gnome-screensaver-3.6.1-27.fc32.x86_64
 Problem 3: package horst-3.0-6.fc23.x86_64 requires libncurses.so.5()(64bit), 
but none of the providers can be installed
  - package horst-3.0-6.fc23.x86_64 requires libtinfo.so.5()(64bit), but none 
of the providers can be installed
  - ncurses-compat-libs-6.2-9.20210508.fc36.x86_64 does not belong to a 
distupgrade repository
  - problem with installed package horst-3.0-6.fc23.x86_64
 Problem 4: package rpmfusion-nonfree-release-36-1.noarch requires 
system-release(36), but none of the providers can be installed
  - fedora-release-workstation-36-20.noarch does not belong to a distupgrade 
repository
  - fedora-release-36-20.noarch does not belong to a distupgrade repository
  - problem with installed package rpmfusion-nonfree-release-36-1.noarch
 Problem 5: problem with installed package 
switchboard-plug-tweaks-1.0.3-3.fc36.x86_64
  - package switchboard-plug-tweaks-1.0.4-2.fc37.x86_64 requires 
switchboard(x86-64), but none of the providers can be installed
  - switchboard-plug-tweaks-1.0.3-3.fc36.x86_64 does not belong to a 
distupgrade repository
  - switchboard-6.0.2-1.fc36.x86_64 does not belong to a distupgrade repository
 Problem 6: package rpmfusion-nonfree-release-36-1.noarch requires 
system-release(36), but none of the providers can be installed
  - package fedora-release-36-20.noarch requires fedora-release-common = 36-20, 
but none of the providers can be installed
  - package fedora-release-workstation-36-20.noarch requires 
fedora-release-common = 36-20, but none of the providers can be installed
  - package fedy-4.8.0-1.fc28.noarch requires rpmfusion-nonfree-release, but 
none of the providers can be installed
  - fedora-release-common-36-20.noarch does not belong to a distupgrade 
repository
  - problem with installed package fedy-4.8.0-1.fc28.noarch
___
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


[Bug 2139510] perl-URI-5.17 is available

2022-11-03 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2139510

Paul Howarth  changed:

   What|Removed |Added

   Fixed In Version||perl-URI-5.17-1.fc38
 Status|ASSIGNED|MODIFIED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139510
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Bug 2139510] perl-URI-5.17 is available

2022-11-03 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=2139510

Paul Howarth  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED
   Assignee|jples...@redhat.com |p...@city-fan.org




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2139510
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Advice on packaging Python with Rust dependency

2022-11-03 Thread Ondrej Pohorelsky
I'm not really sure why upstream did this.
I'll take a look and submit a patch to upstream. Thanks for pointing it out.

On Wed, Nov 2, 2022 at 9:31 PM Fabio Valentini  wrote:

> On Wed, Nov 2, 2022 at 12:42 PM Ondrej Pohorelsky 
> wrote:
> >
> > The missing dependency is pkg-version[0]. It seems like its only outside
> dependency is already packaged[1] in Fedora.
> >
> > It would be great if you could package it. If not, I'll look into it.
> >
> >
> > [0]https://docs.rs/pkg-version/latest/pkg_version/index.html
> > [1]https://src.fedoraproject.org/rpms/rust-proc-macro-hack
>
> I wonder why there need to be two (yes, pkg-version and
> pkg-version-impl) libraries just to read three environment variables?
>
> Are you sure that reading the "CARGO_PKG_VERSION_MAJOR" /
> "CARGO_PKG_VERSION_MINOR" / "CARGO_PKG_VERSION_PATCH" environment
> variables directly wouldn't be ... easier ... than adding two
> additional dependencies?
>
> I mean, I *can* package these two crates, but they are comically small
> (~two dozen lines of code), and their functionality could in most
> cases be replaced with single lines of dependency-free Rust code :(
>
> 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
>


-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

___
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


Announcing spdlog soversion bump

2022-11-03 Thread Vitaly Zaitsev via devel

Hello all.

spdlog 1.11.0 will include a soversion change[1] from .1 to .1.11.

Affected packages (including spdlog-devel and virtual cmake(spdlog) and 
pkgconfig(spdlog)):


- bear
- coeurl
- cryfs
- freeopcua
- gerbera
- gnuradio
- gqrx
- gr-air-modes
- gr-funcube
- gr-hpsdr
- gr-iqbal
- gr-osmosdr
- gr-rds
- libixion
- luxcorerender
- mangohud
- mtxclient
- nheko
- opae
- sdrpp
- wasmedge
- waybar

I will try building all these packages in a COPR repository and then use 
my PP rights to rebuild them in a side tag for Rawhide and F37.


[1]: https://github.com/gabime/spdlog/pull/2376

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
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