date:20230103

https://bugzilla.redhat.com/show_bug.cgi?id=2157630



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2023-6516f36bb9 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-6516f36bb9


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157630
___
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 2158086] New: Add perl-Glib-Object-Introspection to EPEL9

https://bugzilla.redhat.com/show_bug.cgi?id=2158086

Bug ID: 2158086
   Summary: Add perl-Glib-Object-Introspection to EPEL9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Glib-Object-Introspection
  Keywords: FutureFeature
  Assignee: dd...@cpan.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: berra...@redhat.com, dd...@cpan.org,
perl-devel@lists.fedoraproject.org, ser...@serjux.com
Blocks: 2151714
  Target Milestone: ---
Classification: Fedora



Could you please add perl-Glib-Object-Introspection to EPEL9? I need it for
gscan2pdf.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2151714
[Bug 2151714] Please branch and build gscan2pdf in epel9
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2158086
___
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 2157630] Add perl-Image-Sane to EPEL9

https://bugzilla.redhat.com/show_bug.cgi?id=2157630

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-Image-Sane-5-12.el9
 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=2157630
___
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 2157630] Add perl-Image-Sane to EPEL9

https://bugzilla.redhat.com/show_bug.cgi?id=2157630

Petr Pisar  changed:

   What|Removed |Added

Version|rawhide |epel9
 QA Contact|extras...@fedoraproject.org |
Product|Fedora  |Fedora EPEL
  Component|perl-Image-Sane |perl-Image-Sane




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157630
___
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 2158062] New: perl-MCE-1.883 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2158062

Bug ID: 2158062
   Summary: perl-MCE-1.883 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-MCE
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.883
Upstream release that is considered latest: 1.883
Current version/release in rawhide: 1.882-1.fc38
URL: http://search.cpan.org/dist/MCE/

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/5965/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2158062
___
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: "rescue" boot entry files are not updated on OS upgrades

2023-01-03 Thread Samuel Sieb


On 1/3/23 18:02, Sérgio Basto wrote:

But isn't missing inst.rescue boot option [2] ?


That's a different thing.  The rescue kernel is only to have all kernel 
modules available.  The "inst.rescue" mode is available on netinst 
images (and maybe others?) and boots an actual rescue mode that lets you 
mount the installed system for maintenance or repair.

___
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: F38 proposal: X Server Prohibits Byte-swapped Clients (System-Wide Change proposal)

2023-01-03 Thread Peter Hutterer

On Thu, Dec 22, 2022 at 11:30:33AM +0100, Niklas Schnelle wrote:
> Hi All,
> 
> This might not be as niche as you might think. I'm one of the
> Linux kernel maintainers for s390. Many of us do the vast majority of
> their development work natively on s390 systems via SSH from Fedora
> laptops. After all mainframes are pretty damn fast at compiling with
> plenty of memory and dog fooding is part of quality control. And I'm
> sure it's not just the teams working on the Linux kernel but also
> plenty of other people working with s390 Linux machines. These s390
> machines mostly only host X servers via VNC and usually just for the
> installation but they do that too. There is also a hand full of X
> clients I run on s390 which are essential for my and many of my
> colleagues daily workflows. The most important one is defintely
> xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local
> system. Some people also use x3270 via SSH X forwarding from jumphosts,
> others use XEmacs. I also know essential internal tools that are run on
> s390 hosts via X forwarding. Sure people using X forwarding are capable
> of changing configuration defaults but if at all possible I would
> suggest to rethink this, as it will create significant hassle for
> anyone using their Fedora systems to SSH + X forward to s390 Linux
> hosts and it definitely sees more use and thus testing than the
> proposal makes it sound.

One main question here is: how many of you use Wayland already? Right
now the biggest issue with this change is IMO the inability to configure
this for Wayland compositors until they add the respective option. Xorg
is easy to fix with an xorg.conf snippet, but you don't necessarily have
access to how Xwayland is started (mutter certainly is hard-coded).

Cheers,
  Peter
___
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: "rescue" boot entry files are not updated on OS upgrades

2023-01-03 Thread Sérgio Basto

On Tue, 2022-03-01 at 14:37 -0700, Chris Murphy wrote:
> Summary--
> Most all Fedora variants (except Cloud) have a GRUB menu entry
> containing the word "rescue". This kernel+initramfs pair are never
> updated for the life of a Fedora installation. And they quickly
> become
> stale as a Fedora installation ages. This kernel's modules are
> eventually deleted, and if selected at boot time, the typical user
> experience is a dracut shell.
> 
> Basic background-
> (skip this section if you know how it works)
> During a new installation, a single kernel version is installed. e.g.
> 
> vmlinuz-5.17.0-0.rc4.96.fc36.x86_64 which is then duplicated as e.g.
> vmlinuz-0-rescue-3a86878de5d649a983916543ece7bb7e.
> 
> Each of those (identical) kernels has an initramfs file:
> 
> initramfs-5.17.0-0.rc4.96.fc36.x86_64.img
> initramfs-0-rescue-3a86878de5d649a983916543ece7bb7e.img
> 
> The sole difference is the first one is a smaller host-only
> initramfs,
> the second one is a larger no host-only initramfs created with
> `dracut
> -N`. The bigger one just contains a bunch of extra kernel modules and
> dracut scripts, ostensibly to make it more likely to boot a system
> with some change in hardware that the host-only initramfs doesn't
> contain. The size of this rescue initramfs is around 100 MiB, with
> the
> common day to day "host only" initramfs being around 33 MiB. [1]
> 
> As the system is updated, additional kernel versions are installed.
> dnf.conf contains installonly_limit=3, which results in a maximum of
> three kernel versions being installed at a time. Once a fourth kernel
> is installed, the first kernel and its modules are removed from
> /usr/lib/modules. The rescue kernel+initramfs pair are never updated
> or upgraded, even during system upgrades.

Hello, 
I found this email on google , thank you for this "basic background"
lesson .

He also have bug report about this [1], in resume we can regenerate
rescue entry just by delete /boot/*-0-rescue-* files and reinstall the
kernel .

But isn't missing inst.rescue boot option [2] ? 

I also recently did a scratch to fix this bug [3]  


Best regards,


[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1768132 
https://bugzilla.redhat.com/show_bug.cgi?id=1768132#c35

[2]
https://github.com/rhinstaller/anaconda/blob/master/docs/boot-options.rst#instrescue

[3]
https://src.fedoraproject.org/fork/sergiomb/rpms/dracut/blob/rawhide/f/0001-1768132-if-new-Fedora-Release-regenerate-rescue-entr.patch
-- 
Sérgio M. B.
___
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

[EPEL-devel] Fedora EPEL 7 updates-testing report

2023-01-03 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e9a9c081af   
novnc-1.3.0-5.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

dkms-3.0.10-1.el7
nmh-1.8RC1-2.el7
python-importlib-resources-1.0.2-2.el7
viewvc-1.1.29-1.el7

Details about builds:



 dkms-3.0.10-1.el7 (FEDORA-EPEL-2023-f3f32fd1d7)
 Dynamic Kernel Module Support Framework

Update Information:

Bugfixes.

ChangeLog:

* Tue Jan  3 2023 Simone Caronni  - 3.0.10-1
- Update to 3.0.10.

References:

  [ 1 ] Bug #2153850 - there is no "version" field of modinfo nvidia-uvm, and 
the condition for judging whether the installed module is different from the 
tree is refer to the "version"
https://bugzilla.redhat.com/show_bug.cgi?id=2153850




 nmh-1.8RC1-2.el7 (FEDORA-EPEL-2023-817217ba70)
 A capable MIME-email-handling system with a command-line interface

Update Information:

Use links instead of w3m so there isn't a dependence on perl-NKF.

ChangeLog:

* Mon Jan  2 2023 David Levine   - 1.8RC1-2
- Use links instead of w3m so there isn't a dependence on perl-NKF.
* Sun Jan  1 2023 David Levine   - 1.8RC1-1
- With upstream 1.8-RC1.




 python-importlib-resources-1.0.2-2.el7 (FEDORA-EPEL-2023-b0b508c41c)
 Read resources from Python packages

Update Information:

python-importlib-resources build for EPEL 7 as requested

ChangeLog:

* Fri Mar 20 2020 Neal Gompa  - 1.0.2-2
- Rebuild again for EPEL 8
* Thu Nov  7 2019 Ken Dreyer  - 1.0.2-1
- Initial package.

References:

  [ 1 ] Bug #1910124 - Please build python-importlib-resources for EPEL 7
https://bugzilla.redhat.com/show_bug.cgi?id=1910124




 viewvc-1.1.29-1.el7 (FEDORA-EPEL-2023-96ef72f1b2)
 Browser interface for CVS and SVN version control repositories

Update Information:

Fix for CVE-2023-22456: https://github.com/viewvc/viewvc/releases/tag/1.1.29

ChangeLog:

* Wed Jan  4 2023 Bojan Smojver  - 1.1.29-1
- bump up to 1.1.29
- CVE-2023-22456


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

[Bug 2150998] perl-RT-Client-REST-0.71 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2150998

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-RT-Client-REST-0.71-1. |perl-RT-Client-REST-0.71-1.
   |fc38|fc38
   |perl-RT-Client-REST-0.71-1. |perl-RT-Client-REST-0.71-1.
   |fc37|fc37
   ||perl-RT-Client-REST-0.71-1.
   ||fc36



--- Comment #9 from Fedora Update System  ---
FEDORA-2022-8bfb602a86 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
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 2150998] perl-RT-Client-REST-0.71 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2150998

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version|perl-RT-Client-REST-0.71-1. |perl-RT-Client-REST-0.71-1.
   |fc38|fc38
   ||perl-RT-Client-REST-0.71-1.
   ||fc37
Last Closed||2023-01-04 01:23:45



--- Comment #8 from Fedora Update System  ---
FEDORA-2022-10bdbca815 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2150998
___
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 2140480] perl-Dist-Zilla-6.029 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2140480

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|psab...@redhat.com  |mspa...@redhat.com



--- Comment #3 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2140480
___
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 2157775] Please branch and build cpanspec in epel9

https://bugzilla.redhat.com/show_bug.cgi?id=2157775

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|psab...@redhat.com  |mspa...@redhat.com



--- Comment #2 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157775
___
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 671445] [PATCH] specfile accords to new packaging guidelines

https://bugzilla.redhat.com/show_bug.cgi?id=671445

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|psab...@redhat.com  |mspa...@redhat.com



--- Comment #11 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=671445
___
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 2053941] The Fedora BuildRequires is missing an the license files are listed as %doc

https://bugzilla.redhat.com/show_bug.cgi?id=2053941

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|psab...@redhat.com  |mspa...@redhat.com



--- Comment #4 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2053941
___
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 461350] cpanspec nearly always misses the BuildRequires: perl(Test::More)

https://bugzilla.redhat.com/show_bug.cgi?id=461350

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|psab...@redhat.com  |mspa...@redhat.com



--- Comment #12 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=461350
___
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 552105] cpanspec treats recommended dependencies to required

https://bugzilla.redhat.com/show_bug.cgi?id=552105

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|psab...@redhat.com  |mspa...@redhat.com



--- Comment #11 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=552105
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Otto Liljalaakso


Dan Horák kirjoitti 3.1.2023 klo 15.23:

On Tue, 3 Jan 2023 08:14:04 -0500
Stephen Smoogen  wrote:


Could you please elucidate why the command that people have used for nearly
30 years and is the most documented on how to build rpms is broken? And how
people should use instead when they may be dealing with an environment
which doesn't allow fedpkg to work? [AKA I am working on a package which I
want to submit for review so I need to build a @$@$% src RPM somehow and I
am being told I can't use the built in command to do so]


I wonder whether we should start recommending "rpkg" instead of plain
"rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it
quite useful/powerful.


Perhaps we have other places that still recommend rpmbuild for this, but 
at least our "GNU Hello" packaging tutorial [1] currently uses fedpkg 
for this.


The instructions given in the tutorial do work. Unlike Stephen implies, 
fedpkg can be used outside of Git repository for this and other tasks.


This Change will make that tutorial use also rpmautospec. I have a pull 
request ready for that [2].


[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_GNU_Hello/

[2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/102
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 5:10 PM Neal Gompa  wrote:
>
> On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer  wrote:
> >
> > On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
> > >
> > > V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > > that they don't truncate or eliminate the Git history anymore? Because 
> > > > I would
> > > > personally be very displeased if my historical attribution went away
> > > > because of broken processes like the one used to fork all the Fedora
> > > > Linux 34 packages for CentOS Stream 9.
> > > >
> > > It's not only about loosing attributions. There will be NEVRA 
> > > discrepancies in
> > > RHEL:
> > >
> > > Different number of commits will mean different release numbers. That will
> > > break package interdependencies which requires a specific release number. 
> > > E.g
> > > foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus 
> > > Fedora foo
> > > will strengthen the dependency with "Requires: bar >= 1-2". However, after
> > > importing to RHEL, bar will become bar-1-1. The dependency from foo will
> > > break.
> >
> > That's a good point.  The design works well within a single,
> > continuous development environment such as Fedora's but any usage of
> > the sources outside of that, either by importing SRPMs or by importing
> > subsets of dist-git, seems like it would struggle.  Does something
> > like OBS suffer from the same issue?  Seems it would, but I don't know
> > much about how OBS works.
> >
>
> OBS parses the spec file on import and sets the Release value auto
> increment based on the value of the Release field at import time. Then
> when you do a version bump, it resets the Release field back to 1.
>
> OBS does not (by default) let you control the Release field, though a
> project/instance admin can change these defaults. By default, OBS
> overrides the Release value and does its own increments with a commit
> counter and a build counter, formatted as such: .
>
> If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first
> build. Any triggered rebuilds will bump the build counter. When you
> bump to foo-6, then the new build will be foo-6-1.1.
>
> If you want to tweak OBS to retain the spec file Release value, you
> can configure the project or the instance entirely to use another
> scheme. For example, for the OBS project that obsctl is released
> to[1], the scheme is +obs.. That allows the
> original spec file's Release value to remain, while allowing OBS'
> generated data to be appended. You can see this in motion with a build
> of obsctl[2], where you can see that we've done the 6th rebuild of the
> 11th checkin of commit b6e1e99.
>

I should clarify here a bit, this is the 11th checkin into the OBS
SCM, not the 11th checkin of the Git commit:
https://build.opensuse.org/package/revisions/isv:Datto:Utilities:OBSCtl:Mainline/obsctl-git




-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 5:11 PM Neal Gompa  wrote:
>
> On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer  wrote:
> >
> > On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
> > >
> > > V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > > that they don't truncate or eliminate the Git history anymore? Because 
> > > > I would
> > > > personally be very displeased if my historical attribution went away
> > > > because of broken processes like the one used to fork all the Fedora
> > > > Linux 34 packages for CentOS Stream 9.
> > > >
> > > It's not only about loosing attributions. There will be NEVRA 
> > > discrepancies in
> > > RHEL:
> > >
> > > Different number of commits will mean different release numbers. That will
> > > break package interdependencies which requires a specific release number. 
> > > E.g
> > > foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus 
> > > Fedora foo
> > > will strengthen the dependency with "Requires: bar >= 1-2". However, after
> > > importing to RHEL, bar will become bar-1-1. The dependency from foo will
> > > break.
> >
> > That's a good point.  The design works well within a single,
> > continuous development environment such as Fedora's but any usage of
> > the sources outside of that, either by importing SRPMs or by importing
> > subsets of dist-git, seems like it would struggle.  Does something
> > like OBS suffer from the same issue?  Seems it would, but I don't know
> > much about how OBS works.
> >
>
> OBS parses the spec file on import and sets the Release value auto
> increment based on the value of the Release field at import time. Then
> when you do a version bump, it resets the Release field back to 1.
>
> OBS does not (by default) let you control the Release field, though a
> project/instance admin can change these defaults. By default, OBS
> overrides the Release value and does its own increments with a commit
> counter and a build counter, formatted as such: .

Thank you!

josh

>
> If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first
> build. Any triggered rebuilds will bump the build counter. When you
> bump to foo-6, then the new build will be foo-6-1.1.
>
> If you want to tweak OBS to retain the spec file Release value, you
> can configure the project or the instance entirely to use another
> scheme. For example, for the OBS project that obsctl is released
> to[1], the scheme is +obs.. That allows the
> original spec file's Release value to remain, while allowing OBS'
> generated data to be appended. You can see this in motion with a build
> of obsctl[2], where you can see that we've done the 6th rebuild of the
> 11th checkin of commit b6e1e99.
>
> [1]: https://build.opensuse.org/projects/isv:Datto:Utilities:OBSCtl/prjconf
> [2]: 
> https://build.opensuse.org/package/binaries/isv:Datto:Utilities:OBSCtl:Mainline/obsctl-git/Fedora_Rawhide
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 4:02 PM Josh Boyer  wrote:
>
> On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
> >
> > V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > > that they don't truncate or eliminate the Git history anymore? Because I 
> > > would
> > > personally be very displeased if my historical attribution went away
> > > because of broken processes like the one used to fork all the Fedora
> > > Linux 34 packages for CentOS Stream 9.
> > >
> > It's not only about loosing attributions. There will be NEVRA discrepancies 
> > in
> > RHEL:
> >
> > Different number of commits will mean different release numbers. That will
> > break package interdependencies which requires a specific release number. 
> > E.g
> > foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora 
> > foo
> > will strengthen the dependency with "Requires: bar >= 1-2". However, after
> > importing to RHEL, bar will become bar-1-1. The dependency from foo will
> > break.
>
> That's a good point.  The design works well within a single,
> continuous development environment such as Fedora's but any usage of
> the sources outside of that, either by importing SRPMs or by importing
> subsets of dist-git, seems like it would struggle.  Does something
> like OBS suffer from the same issue?  Seems it would, but I don't know
> much about how OBS works.
>

OBS parses the spec file on import and sets the Release value auto
increment based on the value of the Release field at import time. Then
when you do a version bump, it resets the Release field back to 1.

OBS does not (by default) let you control the Release field, though a
project/instance admin can change these defaults. By default, OBS
overrides the Release value and does its own increments with a commit
counter and a build counter, formatted as such: .

If you import foo-5-2 into OBS, it'll do foo-5-2.1 for the first
build. Any triggered rebuilds will bump the build counter. When you
bump to foo-6, then the new build will be foo-6-1.1.

If you want to tweak OBS to retain the spec file Release value, you
can configure the project or the instance entirely to use another
scheme. For example, for the OBS project that obsctl is released
to[1], the scheme is +obs.. That allows the
original spec file's Release value to remain, while allowing OBS'
generated data to be appended. You can see this in motion with a build
of obsctl[2], where you can see that we've done the 6th rebuild of the
11th checkin of commit b6e1e99.

[1]: https://build.opensuse.org/projects/isv:Datto:Utilities:OBSCtl/prjconf
[2]: 
https://build.opensuse.org/package/binaries/isv:Datto:Utilities:OBSCtl:Mainline/obsctl-git/Fedora_Rawhide

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Kalev Lember

On Tue, Jan 3, 2023 at 10:27 PM Otto Liljalaakso 
wrote:

> Kalev Lember kirjoitti 3.1.2023 klo 11.19:
> > We might need to update package maintainer documents to be clear about
> this
> > though, so that people know that they should use 'fedpkg srpm' and not
> > 'rpmbuild -bs'.
>
> In Package Maintainer Docs, we have just a single instance of rpmbuild
> usage, at Using the Koji Build System — Scratch Builds [1]. Everything
> else is fedpkg based already. I made a pull request to get rid of that
> single outlier [2].
>
> Did you have some other source of documentation in mind that would need
> more work?
>
> [1]:
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/#scratch_builds
> [2]:
> https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101


Awesome, thanks for doing that! No, I didn't have anything specific in
mind, so hopefully that was all there was to fix :)

-- 
Kalev
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Otto Liljalaakso

Kalev Lember kirjoitti 3.1.2023 klo 11.19:

On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:

On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:

- fedpkg mockbuild

But it doesn't work correctly (will always use Release: 1) if you run
"rpmbuild -bs foo-bar.spec" which is a very common scenario.

"Doctor, it hurts when I do that."

'rpmbuild -bs' is broken. Don't use it.

Yes, I would say that as well. It's just a low level tool and can never
have all the integration with git that fedpkg has.

We might need to update package maintainer documents to be clear about this
though, so that people know that they should use 'fedpkg srpm' and not
'rpmbuild -bs'.

In Package Maintainer Docs, we have just a single instance of rpmbuild
usage, at Using the Koji Build System — Scratch Builds [1]. Everything
else is fedpkg based already. I made a pull request to get rid of that
single outlier [2].

Did you have some other source of documentation in mind that would need
more work?

[1]:
https://docs.fedoraproject.org/en-US/package-maintainers/Using_the_Koji_Build_System/#scratch_builds

[2]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/101
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 3:30 AM Petr Pisar  wrote:
>
> V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> > Have we made sure that when Red Hat forks Fedora packages for RHEL
> > that they don't truncate or eliminate the Git history anymore? Because I 
> > would
> > personally be very displeased if my historical attribution went away
> > because of broken processes like the one used to fork all the Fedora
> > Linux 34 packages for CentOS Stream 9.
> >
> It's not only about loosing attributions. There will be NEVRA discrepancies in
> RHEL:
>
> Different number of commits will mean different release numbers. That will
> break package interdependencies which requires a specific release number. E.g
> foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo
> will strengthen the dependency with "Requires: bar >= 1-2". However, after
> importing to RHEL, bar will become bar-1-1. The dependency from foo will
> break.

That's a good point.  The design works well within a single,
continuous development environment such as Fedora's but any usage of
the sources outside of that, either by importing SRPMs or by importing
subsets of dist-git, seems like it would struggle.  Does something
like OBS suffer from the same issue?  Seems it would, but I don't know
much about how OBS works.

> Another RHEL problem will be fixes for minor RHEL version. E.g. RHEL 10.0 will
> contain foo-1-1, RHEL-10.1 updates to foo-1-2, then RHEL-10.0 backports
> the change, preferably as foo-1-1.el10_0.1. However, the generated rpmautospec
> schema won't allow it and will produce foo-1-2.el10_0. I foresee RHEL
> maintainers to revert rpmautospec to manual numbering for minor RHEL updates.

Or automation grows the ability to support that kind of versioning, if
it were to be used in RHEL.

> None of these issues are Fedora issues. But considering the ecosystems
> wholistically, the proposed rpmautospec propotion will add a friction.

Nothing is free, that's for sure :)

josh
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Mon, Jan 2, 2023 at 5:56 AM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Monday, 02 January 2023 at 09:57, Miroslav Suchý wrote:
> > Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > > produces bogus changelog messages and artificially
> > > inflates Release counters.
> >
> > I always wondered why people are afraid of gaps in numbering? It is
> > just a number. The number will not object if you skip some of them. :)
>
> Gaps in release numbering are just not neat. To me, they create an
> unnecessary confusion. Each bump in Release field should have a
> corresponding build in koji and it makes me wonder why if it doesn't.

Which means you go and investigate and learn why, which is a sane
thing to do if you want to know that information.

Equating Release values with builds is folly unless the build system
automatically does a build for every commit.  If it did, it could
autogenerate the Release value and probably the changelog oh wait
:)

josh

> > Or it is my origin in BASIC that I am not afraid of that? We numbered
> > the lines as a multiply of 5 or 10. :)
>
> I've written code in BASIC back in the day. This comment is irrelevant
> to the issue at hand.
>
> Regards,
> Dominik
> --
> Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
> There should be a science of discontent. People need hard times and
> oppression to develop psychic muscles.
> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
> ___
> 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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Mon, Jan 2, 2023 at 4:43 AM Maxwell G via devel
 wrote:
>
> On Mon Jan 2, 2023 at 09:57 +0100, Miroslav Suchý wrote:
> > Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a):
> > > produces bogus changelog messages and artificially
> > > inflates Release counters.
> >
> > I always wondered why people are afraid of gaps in numbering? It is
> > just a number. The number will not object if you skip some of them. :)
>
> The release number shows how many builds of the same version have been
> made. A high release is also baseline indicator that a package/project
> is stale downstream and/or upstream. When the first build of foo v1.5.0
> is foo-1.5.0-6 because the author took the time to split up logical
> changes into separate commits, the value of that release number is lost.

The heuristics you are describing are assumptions, not facts.  They
are decent assumptions in the context of the Fedora project, but they
don't necessarily actually apply equally across the package set.

Personally, I think we should avoid tying any assumption to the
Release value and simply realize that it is the mechanism used to
present an update to a system.  Guessing what foo-1.5.0-6 vs.
foo-1.5.0-560 means based on what we think Release denotes is kind of
dangerous.

josh
___
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 2132181] perl-Net-DNS-1.36 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2132181

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-Net-DNS-1.36-1.fc38
 Resolution|--- |ERRATA
Last Closed||2023-01-03 20:31:37



--- Comment #7 from Fedora Update System  ---
FEDORA-2023-e83b99da45 has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2132181
___
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 2132181] perl-Net-DNS-1.36 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2132181

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #6 from Fedora Update System  ---
FEDORA-2023-e83b99da45 has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-e83b99da45


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2132181
___
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 2015018] Upgrade perl-Net-DNS-SEC to 1.19

https://bugzilla.redhat.com/show_bug.cgi?id=2015018

Paul Wouters  changed:

   What|Removed |Added

 Resolution|--- |CURRENTRELEASE
 Status|RELEASE_PENDING |CLOSED
Last Closed||2023-01-03 19:51:31




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2015018
___
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: Orphaning dlib

2023-01-03 Thread Onuralp SEZER

I will gladly take it, and any co-maintainers are welcome as well.

Thank you for your contributions to dlib as well.

On Tue, Jan 3, 2023 at 10:11 AM Luya Tshimbalanga 
wrote:

> Hello team,
>
> I am orphaning dlib as I no longer need it for dependencies like howdly
> (Windows Hello type authentication app) and I no longer have a 2018 HP Envy
> 2-in-1 device for testing. The package is well maintained and  up to date
> with upstream. Feel free to take it.
>
> Reference: https://src.fedoraproject.org/rpms/dlib/
>
> --
> Luya Tshimbalanga
> Fedora Design Team
> Fedora Design Suite maintainer
>
> ___
> 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
>


-- 





---
Onuralp SEZER
Fedora Ambassadors  EMEA
 Member / Turkey
Fedora KDE-Sig Member
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Todd Zullinger

Zbigniew Jędrzejewski-Szmek wrote:
> Yes, this is what I was talking about too. Because rpmbuild does not set
> %_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
> versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
> Personally, I have dozens of stray files there from old rpm builds there…

I've used the following in ~/.rpmmacros for many years to
have rpmbuild keep package files together, as rpkg/fedpkg
do:

%_sourcedir %{_topdir}/%{?name:%name}
%_specdir   %{_sourcedir}
%_builddir  %{_sourcedir}
%_srcrpmdir %{_sourcedir}
%_rpmdir%{_sourcedir}

That doesn't address the deeper issues with respect to
rpmautospec compatibility, but it does make rpmbuild much
more comfortable to use, at least for me.

-- 
Todd


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

Summary/Minutes from today's FESCo Meeting (2023-01-03)


(once again with a proper Subject line)

===
#fedora-meeting: FESCO (2023-01-03)
===


Meeting started by mhroncok at 17:01:53 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-03/fesco.2023-01-03-17.01.log.html
.



Meeting summary
---
* init process  (mhroncok, 17:02:08)

* #2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to
  default   (mhroncok, 17:06:26)
  * LINK:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/230
is the implementation  (davide, 17:13:47)
  * AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora
Linux 38 and we evaluate whether to retain it by Fedora Linux 40.
This Change must be implemented in a manner which packages are able
to trivially opt-out of retaining frame pointers during compilation
so that packages that take larger performance hits can easily
revert.  (mhroncok, 17:20:38)
  * Change owners please coordinate the change with the Python
Maintainers before changing the defaults  (mhroncok, 17:21:20)

* Next week's chair  (mhroncok, 17:21:46)
  * ACTION: Conan Kudo will probably chair next meeting  (mhroncok,
17:22:17)

* Open Floor  (mhroncok, 17:23:10)

* #2907 Exception for spliting OpenJDK build and integration  (mhroncok,
  17:23:47)
  * AGREED: No exception is needed (+5,1,-0)  (mhroncok, 17:31:20)

* Open Floor  (mhroncok, 17:31:52)

Meeting ended at 17:42:06 UTC.




Action Items

* Conan Kudo will probably chair next meeting




Action Items, by person
---
* **UNASSIGNED**
  * Conan Kudo will probably chair next meeting




People Present (lines said)
---
* mhroncok (66)
* zbyszek (27)
* Eighth_Doctor (25)
* zodbot (20)
* hergertme (13)
* mhayden (9)
* davide (6)
* dcantrell (4)
* music[m] (2)
* salimma (1)
* MichaelCatanzaro (1)
* nirik (0)
* decathorpe (0)
* sgallagh (0)
* music (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* Son_Goku (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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: Schedule for Tuesday's FESCo Meeting (2023-01-03)


===
#fedora-meeting: FESCO (2023-01-03)
===


Meeting started by mhroncok at 17:01:53 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2023-01-03/fesco.2023-01-03-17.01.log.html
.



Meeting summary
---
* init process  (mhroncok, 17:02:08)

* #2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to
  default   (mhroncok, 17:06:26)
  * LINK:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/230
is the implementation  (davide, 17:13:47)
  * AGREED: APPROVED (+6,1,-1) This Change is implemented for Fedora
Linux 38 and we evaluate whether to retain it by Fedora Linux 40.
This Change must be implemented in a manner which packages are able
to trivially opt-out of retaining frame pointers during compilation
so that packages that take larger performance hits can easily
revert.  (mhroncok, 17:20:38)
  * Change owners please coordinate the change with the Python
Maintainers before changing the defaults  (mhroncok, 17:21:20)

* Next week's chair  (mhroncok, 17:21:46)
  * ACTION: Conan Kudo will probably chair next meeting  (mhroncok,
17:22:17)

* Open Floor  (mhroncok, 17:23:10)

* #2907 Exception for spliting OpenJDK build and integration  (mhroncok,
  17:23:47)
  * AGREED: No exception is needed (+5,1,-0)  (mhroncok, 17:31:20)

* Open Floor  (mhroncok, 17:31:52)

Meeting ended at 17:42:06 UTC.




Action Items

* Conan Kudo will probably chair next meeting




Action Items, by person
---
* **UNASSIGNED**
  * Conan Kudo will probably chair next meeting




People Present (lines said)
---
* mhroncok (66)
* zbyszek (27)
* Eighth_Doctor (25)
* zodbot (20)
* hergertme (13)
* mhayden (9)
* davide (6)
* dcantrell (4)
* music[m] (2)
* salimma (1)
* MichaelCatanzaro (1)
* nirik (0)
* decathorpe (0)
* sgallagh (0)
* music (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* Son_Goku (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)




Generated by `MeetBot`_ 0.4

.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
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 1716324] Module::Build lists the object files after the linker flags, causing underlinking with -Wl,--as-needed

https://bugzilla.redhat.com/show_bug.cgi?id=1716324

Michal Josef Spacek  changed:

   What|Removed |Added

 CC||mspa...@redhat.com



--- Comment #12 from Michal Josef Spacek  ---
(In reply to Paul Howarth from comment #4)
> On the other hand, the ExtUtils::CBuilder::Platform::android module already 
> has
> code to add libperl to the mix, and does it by fiddling with
> $args{extra_linker_flags} instead. Maybe our patch should do the same?

I think yes.

This issue isn't related to Fedora settings. The same situation is in Debian or
a fresh install of the Text::Xslate.
There are many similar issues in Fedora: like perl-Data-MessagePack


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1716324
___
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: Orphaned packages looking for new maintainers

2023-01-03 Thread Robby Callicotte via devel

On Monday, January 2, 2023 7:25:39 PM CST Robby Callicotte wrote:
> On January 2, 2023 6:45:53 PM CST, Maxwell G  wrote:
> >On Mon Jan 2, 2023 at 11:46 -0600, Robby Callicotte via devel wrote:
> >> I went ahead and took vim-nerdtree.
> >
> >FYI: Nerdtree is unmaintained upstream:
> >https://github.com/preservim/nerdtree/issues/1280
> >
> >--
> >Maxwell G (@gotmax23)
> >Pronouns: He/Him/His

That thread still appears to be active,  several folks have stepped up to the 
plate... They just need a main person as maintainer.  I'm confident that such a 
person will appear soon.  :)

-- 
Robby Callicotte
He/Him/His
Timezone: America/Chicago
IRC: c4t3l | Twitter: @robbycl2v

___
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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2023-01-03 Thread tdawson

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2023-01-04 from 16:00:00 to 17:00:00 US/Eastern
   At fedora-meet...@irc.libera.chat

The meeting will be about:
This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




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

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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)



Dne 03. 01. 23 v 16:24 Neal Gompa napsal(a):

On Tue, Jan 3, 2023 at 10:21 AM Zbigniew Jędrzejewski-Szmek
 wrote:

On Tue, Jan 03, 2023 at 03:50:10PM +0100, Vít Ondruch wrote:

Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):

On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  wrote:


On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek  
wrote:

On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:

On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:

- fedpkg mockbuild

But it doesn't work correctly (will always use Release: 1) if you run
"rpmbuild -bs foo-bar.spec" which is a very common scenario.

"Doctor, it hurts when I do that."

'rpmbuild -bs' is broken. Don't use it.


Could you please elucidate why the command that people have used for nearly 30 
years and is the most documented on how to build rpms is broken? And how people 
should use instead when they may be dealing with an environment which doesn't 
allow fedpkg to work? [AKA I am working on a package which I want to submit for 
review so I need to build a @$@$% src RPM somehow and I am being told I can't 
use the built in command to do so]

"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
(because it's implemented on top of RPM instead of *in* RPM),


Oh, it does not know about more things, e.g.:

~~~

$ rpmbuild -bs ruby.spec
error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to
load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby
   0<  (%load)
~~~

Yes, this is what I was talking about too. Because rpmbuild does not set
%_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
Personally, I have dozens of stray files there from old rpm builds there…


So it does not handle more scenarios then just rpmautospec.
IMHO, it would be much better to recommend:

$ touch sources
$ fedpkg --release f38 srpm

Ideally, fedpkg/rpkg would allow 'sources' to not exist and DTRT automatically.
It would just make everyone's life easier.


It already does. I use it for packaging I have in Git repos on
pagure.io.




Oh really? Very nice. Have not noticed it yet. Thx for heads up.


Vít




--
真実はいつも一つ！/ Always, there's only one truth!
___
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


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

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)


Dne 03. 01. 23 v 4:30 Kevin Kofler via devel napsal(a):

Fabio Valentini wrote:

- incompatible compile-time options (i.e. resulting in conditional
compilation): different packages depend on crates with different sets
of features enabled, sometimes with conflicting options. Even with a
stable ABI, you'd need to build crates for all necessary combinations
of configurations, and that matrix quickly explodes (i.e. usually
exponentially - 2^n builds for for n independent flags). This is a
deal-breaker for shared libraries in most cases, and also can't be
solved by using a different compiler. (Unless you want to figure out
*which* combinations to build, and *only* build these.)



I wish this was specific to Rust. We more or less deal with this issue 
in every ecosystem. We just sometimes choose to ignore the whole parts 
of the matrix, e.g. statically/dynamically linked libraries. But also 
support for some extensions, such as e.g. language bindings and what 
not. Or maybe platform support.




Let me try formulating my criticism more constructively (since my previous
reply failed both at being polite and at getting my point through, sorry
again for that):

I am really surprised to read above that Rust apparently allows applications
to pick the flag with which the libraries they depend on are compiled. I
really have to wonder why anyone would think that allowing that would be a
good idea, but then again I guess I know the answer: Whoever added this
feature was so set in a mindset where everything is compiled on demand and
statically linked that they figured: why not?

And if you are in that mindset, that actually sounds like a reasonable call
to make. Source-based software distributions do have the advantage of
offering this kind of flexibility on demand, see also the USE flags in
Gentoo. Those are in fact one of the main reasons some people decide to
compile an entire GNU/Linux distribution from source (and hence pick a
distribution such as Gentoo) to begin with. Likewise, the Rust way of
compiling dependencies on demand allows applications to make this kind of
settings for them.

Still, I can see several issues with that approach, e.g., what if an
application depends on two libraries A and B that both depend on library C,
but with conflicting flags? But the main issue is that, as you point out, it
makes binary distribution of shared libraries highly impractical. That is
why I think this was a short-sighted design decision.

But we will have to work around this one way or another, because I doubt
anyone will be willing to remove that questionable feature now that
developers have come to rely on it. (And no, I do not think the current
Fedora approach of packaging crates in source form only is the optimal
approach, for reasons I have already pointed out in other threads on this
list.)



We don't need to remove this feature, just limit the scope into 
acceptable size.



Vít




I hope that the above now brings my point across constructively.

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


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

Re: Self Introduction: Dale Turner



Dne 03. 01. 23 v 14:16 Sandro napsal(a):

On 26-12-2022 19:18, Dale Turner via devel wrote:

The main reason for me finally posting to this list is that I noticed
xaos is now unmaintained. I am not in the Packager group, but I think
I would be able to maintain this package, or at least assist. It is
not critical to any system, but is interesting to me, and hopefully
would not be too daunting a task. I do have a successful build in my
COPR.


Hi Dale,

Welcome to the Fedora community!

I've adopted xaos to safeguard it from retirement. I'll be glad to 
hand it over to you once you have become a Fedora packager.



Sandro, since you have adopted the package, you can also help Dale with 
becoming packager:


https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#comaintainer

Dale, there is also this way to become packager:

https://docs.fedoraproject.org/en-US/fesco/Packager_sponsor_policy/#adopting

Depends how confident you are with packaging and how much guidance you need.


Vít




You will need to follow the process outlined in the docs [1], which 
I'm sure you have already looked at. ;)


Have you submitted a package for review, yet? If so, I'd be willing to 
do a preliminary review. Unfortunately, I'm not a sponsor myself, but 
at least it will set the wheels in motion.


[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/


Cheers,




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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 10:21 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Tue, Jan 03, 2023 at 03:50:10PM +0100, Vít Ondruch wrote:
> >
> > Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):
> > > On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  
> > > wrote:
> > > >
> > > >
> > > > On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
> > > >  wrote:
> > > > > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel 
> > > > > wrote:
> > > > > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > > - fedpkg mockbuild
> > > > > > But it doesn't work correctly (will always use Release: 1) if you 
> > > > > > run
> > > > > > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
> > > > > "Doctor, it hurts when I do that."
> > > > >
> > > > > 'rpmbuild -bs' is broken. Don't use it.
> > > > >
> > > > Could you please elucidate why the command that people have used for 
> > > > nearly 30 years and is the most documented on how to build rpms is 
> > > > broken? And how people should use instead when they may be dealing with 
> > > > an environment which doesn't allow fedpkg to work? [AKA I am working on 
> > > > a package which I want to submit for review so I need to build a @$@$% 
> > > > src RPM somehow and I am being told I can't use the built in command to 
> > > > do so]
> > > "rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
> > > (because it's implemented on top of RPM instead of *in* RPM),
> >
> >
> > Oh, it does not know about more things, e.g.:
> >
> > ~~~
> >
> > $ rpmbuild -bs ruby.spec
> > error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to
> > load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby
> >   0<  (%load)
> > ~~~
>
> Yes, this is what I was talking about too. Because rpmbuild does not set
> %_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
> versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
> Personally, I have dozens of stray files there from old rpm builds there…
>
> > So it does not handle more scenarios then just rpmautospec.
>
> > IMHO, it would be much better to recommend:
> >
> > $ touch sources
> > $ fedpkg --release f38 srpm
>
> Ideally, fedpkg/rpkg would allow 'sources' to not exist and DTRT 
> automatically.
> It would just make everyone's life easier.
>

It already does. I use it for packaging I have in Git repos on
pagure.io.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 03, 2023 at 03:50:10PM +0100, Vít Ondruch wrote:
> 
> Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):
> > On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  wrote:
> > > 
> > > 
> > > On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
> > >  wrote:
> > > > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel 
> > > > wrote:
> > > > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > > - fedpkg mockbuild
> > > > > But it doesn't work correctly (will always use Release: 1) if you run
> > > > > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
> > > > "Doctor, it hurts when I do that."
> > > > 
> > > > 'rpmbuild -bs' is broken. Don't use it.
> > > > 
> > > Could you please elucidate why the command that people have used for 
> > > nearly 30 years and is the most documented on how to build rpms is 
> > > broken? And how people should use instead when they may be dealing with 
> > > an environment which doesn't allow fedpkg to work? [AKA I am working on a 
> > > package which I want to submit for review so I need to build a @$@$% src 
> > > RPM somehow and I am being told I can't use the built in command to do so]
> > "rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
> > (because it's implemented on top of RPM instead of *in* RPM),
> 
> 
> Oh, it does not know about more things, e.g.:
> 
> ~~~
> 
> $ rpmbuild -bs ruby.spec
> error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to
> load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby
>   0<  (%load)
> ~~~

Yes, this is what I was talking about too. Because rpmbuild does not set
%_sourcedir, it may fail to load some files. Even worse, it may load *wrong*
versions, e.g. when some old version is present in the ~/rpmbuild/SOURCES/.
Personally, I have dozens of stray files there from old rpm builds there…

> So it does not handle more scenarios then just rpmautospec.

> IMHO, it would be much better to recommend:
> 
> $ touch sources
> $ fedpkg --release f38 srpm

Ideally, fedpkg/rpkg would allow 'sources' to not exist and DTRT automatically.
It would just make everyone's life easier.

Zbyszek
___
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: old llvm/clang (14.0.6) in current epel9 build system while mock build has new version of clang/llvm (15.0.1)

2023-01-03 Thread Than Ngo

it is the standard mock build (centos-stream+epel-9-x86_64) which 
includes centos-stream-9 and epel-9 repo.


Thanks,
Than

Am 03.01.23 um 14:47 schrieb Florian Weimer:

* Than Ngo:


our current build system for epel9 contains old version (14.0.6) of
llvm/clang while mock build has the new version of clang/llvm
(15.0.1).
there is bug in llvm 14.0.6 that causes linking error when building
chromium. The bug was fixed in llvm-15.x.

Is it possible to get new version of llvm/clang (15.0.1) in build
system for epel9?

What “mock build” are you refering to?  Is it about the c9s buildroot?
That's only compatible with epel-next, not epel, as far as I understand
it.

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: rpmautospec - how to add suffix to the current release and don't bump it right now

2023-01-03 Thread Zdenek Dohnal


On 1/3/23 12:19, Zbigniew Jędrzejewski-Szmek wrote:



Is this doable with rpmautospec and if it is, how?

The desired effect can be implemented by overriding %dist:

   %global dist %dist~test.0
   Release: %autorelease

Notice that I used '~' to make the redefined %dist _lower_ than the original.
Let's say that the last official build had Release==1.
When this spec is built, you end up with Release==2.fc38~test.0.
When the %dist override is removed, and the package is built officially,
we end up with Release==2.fc38  (2.fc38~test.0 < 2.fc38).


Thanks, Zbyszek! That's exactly I was looking for.

Zdenek



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


--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)



Dne 03. 01. 23 v 14:20 Fabio Valentini napsal(a):

On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  wrote:



On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek  
wrote:

On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:

On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:

- fedpkg mockbuild

But it doesn't work correctly (will always use Release: 1) if you run
"rpmbuild -bs foo-bar.spec" which is a very common scenario.

"Doctor, it hurts when I do that."

'rpmbuild -bs' is broken. Don't use it.


Could you please elucidate why the command that people have used for nearly 30 
years and is the most documented on how to build rpms is broken? And how people 
should use instead when they may be dealing with an environment which doesn't 
allow fedpkg to work? [AKA I am working on a package which I want to submit for 
review so I need to build a @$@$% src RPM somehow and I am being told I can't 
use the built in command to do so]

"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
(because it's implemented on top of RPM instead of *in* RPM),



Oh, it does not know about more things, e.g.:

~~~

$ rpmbuild -bs ruby.spec
error: /home/vondruch/fedora-scm/own/ruby/ruby.spec: line 132: failed to 
load macro file /home/vondruch/rpmbuild/SOURCES/macros.ruby

  0<  (%load)
~~~

So it does not handle more scenarios then just rpmautospec.



  but it
will still produce a valid SRPM file, just with default fallback
values for both %autorelease (i.e. 1%{?dist}) and %autochangelog (i.e.
empty). I even still recommend "rpmbuild -bs" to "new packagers" for
building an SRPM outside a dist-git repository (for example, for
submitting it for package review).



IMHO, it would be much better to recommend:


~~~

$ touch sources

$ fedpkg --release f38 srpm

~~~


instead.



Vít



But for building an SRPM in a
dist-git repo, "fedpkg srpm" is absolutely the better choice.

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


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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Richard Hughes

On Tue, 3 Jan 2023 at 13:46, Florian Weimer  wrote:
> > BuildError: Error running GIT command "git clone -n
> > https://src.fedoraproject.org/rpms/fwupd.git
> > /var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd",
> > see checkout.log for details
> | fatal: the remote end hung up unexpectedly
> So maybe an unrelated issue?  I mean, at this point the system won't
> even know that the package uses rpmautospec.

You're correct indeed, thanks. It seems to be a spurious error. The
package is building happily now.

Richard.
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Stephen Smoogen

On Tue, 3 Jan 2023 at 08:14, Stephen Smoogen  wrote:

>
>
> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
>> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
>> > > - fedpkg mockbuild
>> >
>> > But it doesn't work correctly (will always use Release: 1) if you run
>> > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>>
>> "Doctor, it hurts when I do that."
>>
>> 'rpmbuild -bs' is broken. Don't use it.
>>
>>
> Could you please elucidate why the command that people have used for
> nearly 30 years and is the most documented on how to build rpms is broken?
> And how people should use instead when they may be dealing with an
> environment which doesn't allow fedpkg to work? [AKA I am working on a
> package which I want to submit for review so I need to build a @$@$% src
> RPM somehow and I am being told I can't use the built in command to do so]
>
>
>
OK I have started off the year with a cranky email. My apologies for that
as I should have gone back to read the context which this was being said
in. [I am usually all for removing extra stuff from an email to make it
short and sweet, and then go read what I might have missed.. however in
this case I didn't and just barked like a mad dog.]


> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle.
> -- Ian MacClaren
>


-- 
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: old llvm/clang (14.0.6) in current epel9 build system while mock build has new version of clang/llvm (15.0.1)

* Than Ngo:

> our current build system for epel9 contains old version (14.0.6) of
> llvm/clang while mock build has the new version of clang/llvm
> (15.0.1).
> there is bug in llvm 14.0.6 that causes linking error when building
> chromium. The bug was fixed in llvm-15.x.
>
> Is it possible to get new version of llvm/clang (15.0.1) in build
> system for epel9?

What “mock build” are you refering to?  Is it about the c9s buildroot?
That's only compatible with epel-next, not epel, as far as I understand
it.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

* Richard Hughes:

> On Fri, 30 Dec 2022 at 19:02, Ben Cotton  wrote:
>> Version: 1.2.3
>> Release: %autorelease
>> %autochangelog
>
> I tied this on a package this morning and got:
>
> BuildError: Error running GIT command "git clone -n
> https://src.fedoraproject.org/rpms/fwupd.git
> /var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd",
> see checkout.log for details

That log says:

| $ git clone -n https://src.fedoraproject.org/rpms/fwupd.git 
/var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd
| Cloning into 
'/var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd'...
| error: RPC failed; curl 16 Error in the HTTP2 framing layer
| fatal: the remote end hung up unexpectedly

So maybe an unrelated issue?  I mean, at this point the system won't
even know that the package uses rpmautospec.

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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

* Stephen Smoogen:

> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek  
> wrote:
>
>  On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
>  > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
>  > > - fedpkg mockbuild
>  > 
>  > But it doesn't work correctly (will always use Release: 1) if you run
>  > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>
>  "Doctor, it hurts when I do that."
>
>  'rpmbuild -bs' is broken. Don't use it.
>
> Could you please elucidate why the command that people have used for
> nearly 30 years and is the most documented on how to build rpms is
> broken?

It's never been a reliable way to create a source RPM from a dist-git
checkout.  For example, it does not ensure that all the necessary
dependencies are installed, or that all the RPM macros are set up
correctly.

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

[Bug 2157243] perl-Throwable-1.001 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157243

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE
   Fixed In Version||perl-Throwable-1.001-1.fc38
Last Closed||2023-01-03 13:42:53




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157243
___
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-Throwable] PR #1: 1.001 bump; Package tests


jplesnik merged a pull-request against the project: `perl-Throwable` that you 
are following.

Merged pull-request:

``
1.001 bump; Package tests
``

https://src.fedoraproject.org/rpms/perl-Throwable/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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 3, 2023 at 8:24 AM Dan Horák  wrote:
>
> On Tue, 3 Jan 2023 08:14:04 -0500
> Stephen Smoogen  wrote:
>
> > On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
> > wrote:
> >
> > > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > > > - fedpkg mockbuild
> > > >
> > > > But it doesn't work correctly (will always use Release: 1) if you run
> > > > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
> > >
> > > "Doctor, it hurts when I do that."
> > >
> > > 'rpmbuild -bs' is broken. Don't use it.
> > >
> > >
> > Could you please elucidate why the command that people have used for nearly
> > 30 years and is the most documented on how to build rpms is broken? And how
> > people should use instead when they may be dealing with an environment
> > which doesn't allow fedpkg to work? [AKA I am working on a package which I
> > want to submit for review so I need to build a @$@$% src RPM somehow and I
> > am being told I can't use the built in command to do so]
>
> I wonder whether we should start recommending "rpkg" instead of plain
> "rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it
> quite useful/powerful.
>

As I understand it, rpkg is not maintained, so that would be a poor choice.




--
真実はいつも一つ！/ Always, there's only one truth!
___
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: old llvm/clang (14.0.6) in current epel9 build system while mock build has new version of clang/llvm (15.0.1)

2023-01-03 Thread Stephen Smoogen

On Tue, 3 Jan 2023 at 07:55, Than Ngo  wrote:

> Hi,
>
> our current build system for epel9 contains old version (14.0.6) of
> llvm/clang while mock build has the new version of clang/llvm (15.0.1).
> there is bug in llvm 14.0.6 that causes linking error when building
> chromium. The bug was fixed in llvm-15.x.
>
>
The EPEL build system has been pushed to the CDN for RHEL9 which is
currently 14.0.6. Is your mock build using the CDN or somehow using either
CentOS Stream 9 or some other package set?

You will either need to:
1. Wait until LLVM-15 is released for RHEL-9 (which looks like 9.2 in
October/November)
2. Aim your builds at epel-next so it is using the CentOS Stream 9 packages
3. Work with whatever team 'owns' llvm and see if they can get a fix out to
the 9.1 stream
4. something else?



> Is it possible to get new version of llvm/clang (15.0.1) in build system
> for epel9?
>
> Than
> ___
> 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
>


-- 
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Dan Horák

On Tue, 3 Jan 2023 08:14:04 -0500
Stephen Smoogen  wrote:

> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
> wrote:
> 
> > On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > > - fedpkg mockbuild
> > >
> > > But it doesn't work correctly (will always use Release: 1) if you run
> > > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
> >
> > "Doctor, it hurts when I do that."
> >
> > 'rpmbuild -bs' is broken. Don't use it.
> >
> >
> Could you please elucidate why the command that people have used for nearly
> 30 years and is the most documented on how to build rpms is broken? And how
> people should use instead when they may be dealing with an environment
> which doesn't allow fedpkg to work? [AKA I am working on a package which I
> want to submit for review so I need to build a @$@$% src RPM somehow and I
> am being told I can't use the built in command to do so]

I wonder whether we should start recommending "rpkg" instead of plain
"rpmbuild" for the initial/non-dist-git work on rpms ... I am finding it
quite useful/powerful.


Dan
___
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 2157893] New: perl-Data-Peek-0.52 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157893

Bug ID: 2157893
   Summary: perl-Data-Peek-0.52 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Data-Peek
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
mspa...@redhat.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 0.52
Upstream release that is considered latest: 0.52
Current version/release in rawhide: 0.51-4.fc37
URL: http://search.cpan.org/dist/Data-Peek/

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/2770/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157893
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Fabio Valentini

On Tue, Jan 3, 2023 at 2:14 PM Stephen Smoogen  wrote:
>
>
>
> On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek  
> wrote:
>>
>> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
>> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
>> > > - fedpkg mockbuild
>> >
>> > But it doesn't work correctly (will always use Release: 1) if you run
>> > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>>
>> "Doctor, it hurts when I do that."
>>
>> 'rpmbuild -bs' is broken. Don't use it.
>>
>
> Could you please elucidate why the command that people have used for nearly 
> 30 years and is the most documented on how to build rpms is broken? And how 
> people should use instead when they may be dealing with an environment which 
> doesn't allow fedpkg to work? [AKA I am working on a package which I want to 
> submit for review so I need to build a @$@$% src RPM somehow and I am being 
> told I can't use the built in command to do so]

"rpmbuild -bs" is not "broken", it just doesn't know about rpmautospec
(because it's implemented on top of RPM instead of *in* RPM), but it
will still produce a valid SRPM file, just with default fallback
values for both %autorelease (i.e. 1%{?dist}) and %autochangelog (i.e.
empty). I even still recommend "rpmbuild -bs" to "new packagers" for
building an SRPM outside a dist-git repository (for example, for
submitting it for package review). But for building an SRPM in a
dist-git repo, "fedpkg srpm" is absolutely the better choice.

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: Orphaned packages looking for new maintainers

2023-01-03 Thread Sandro


On 02-01-2023 19:21, Dale Turner via devel wrote:

As I mentioned last week, I would be interested in xaos. BUT, I am
not presently a packager/maintainer...


I've taken xaos for safekeeping as explained in my reply to Dale's 
introduction.


-- Sandro
___
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: Self Introduction: Dale Turner

2023-01-03 Thread Sandro


On 26-12-2022 19:18, Dale Turner via devel wrote:

The main reason for me finally posting to this list is that I noticed
xaos is now unmaintained. I am not in the Packager group, but I think
I would be able to maintain this package, or at least assist. It is
not critical to any system, but is interesting to me, and hopefully
would not be too daunting a task. I do have a successful build in my
COPR.


Hi Dale,

Welcome to the Fedora community!

I've adopted xaos to safeguard it from retirement. I'll be glad to hand 
it over to you once you have become a Fedora packager.


You will need to follow the process outlined in the docs [1], which I'm 
sure you have already looked at. ;)


Have you submitted a package for review, yet? If so, I'd be willing to 
do a preliminary review. Unfortunately, I'm not a sponsor myself, but at 
least it will set the wheels in motion.


[1] 
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/


Cheers,


--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Stephen Smoogen

On Tue, 3 Jan 2023 at 04:20, Zbigniew Jędrzejewski-Szmek 
wrote:

> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > - fedpkg mockbuild
> >
> > But it doesn't work correctly (will always use Release: 1) if you run
> > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>
> "Doctor, it hurts when I do that."
>
> 'rpmbuild -bs' is broken. Don't use it.
>
>
Could you please elucidate why the command that people have used for nearly
30 years and is the most documented on how to build rpms is broken? And how
people should use instead when they may be dealing with an environment
which doesn't allow fedpkg to work? [AKA I am working on a package which I
want to submit for review so I need to build a @$@$% src RPM somehow and I
am being told I can't use the built in command to do so]


-- 
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: Orphaned packages looking for new maintainers

2023-01-03 Thread Dale Turner via devel






Sent with Proton Mail secure email.

--- Original Message ---
On Tuesday, January 3rd, 2023 at 2:22 AM, Alexander Ploumistos 
 wrote:


> On Mon, Jan 2, 2023 at 7:21 PM Dale Turner via devel
> devel@lists.fedoraproject.org wrote:
> 
> > As I mentioned last week, I would be interested in xaos. BUT, I am not 
> > presently a packager/maintainer...
> 
> 
> Hi Dale,
> 
> Unfortunately there's nothing that can be done (except perhaps
> delaying the retirement of xaos) until you become a package
> maintainer:
> https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
> 
> If it does get a "stay of execution", you will be able to claim it
> once you are in the packagers group, but even if that doesn't happen,
> you will be able to get it reintroduced into the distribution.
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

Alexander,

Thank you for the reply. I did read the docs. I was attempting to do what was 
outlined in 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/
 regarding orphaned packages. 

I appreciate the time. I hope I am not using this devel list inappropriately, 
and I sincerely apologise if so.

Thanks.

Dale
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Richard Hughes

On Fri, 30 Dec 2022 at 19:02, Ben Cotton  wrote:
> Version: 1.2.3
> Release: %autorelease
> %autochangelog

I tied this on a package this morning and got:

BuildError: Error running GIT command "git clone -n
https://src.fedoraproject.org/rpms/fwupd.git
/var/lib/mock/f38-build-4075-4953952/root/chroot_tmpdir/scmroot/fwupd",
see checkout.log for details

The page is here if that helps:
https://koji.fedoraproject.org/koji/taskinfo?taskID=95738071 -- this
is from a "git push && fedpkg build" from the main branch. Any ideas?

Richard.
___
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-Throwable] PR #1: 1.001 bump; Package tests


jplesnik opened a new pull-request against the project: `perl-Throwable` that 
you are following:
``
1.001 bump; Package tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Throwable/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

old llvm/clang (14.0.6) in current epel9 build system while mock build has new version of clang/llvm (15.0.1)

2023-01-03 Thread Than Ngo


Hi,

our current build system for epel9 contains old version (14.0.6) of 
llvm/clang while mock build has the new version of clang/llvm (15.0.1).
there is bug in llvm 14.0.6 that causes linking error when building 
chromium. The bug was fixed in llvm-15.x.


Is it possible to get new version of llvm/clang (15.0.1) in build system 
for epel9?


Than
___
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 2157240] perl-Perl-PrereqScanner-1.025 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157240

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Perl-PrereqScanner-1.0
   ||25-1.fc38
Last Closed||2023-01-03 12:09:13




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157240
___
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 2157235] perl-CPAN-Uploader-0.103017 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157235

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-CPAN-Uploader-0.103017
   ||-1.fc38
Last Closed||2023-01-03 11:58:48




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157235
___
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 2157228] perl-Sub-Exporter-GlobExporter-0.006 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157228

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
   Fixed In Version||perl-Sub-Exporter-GlobExpor
   ||ter-0.006-1.fc38
 Status|ASSIGNED|CLOSED
Last Closed||2023-01-03 11:57:09




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157228
___
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-Sub-Exporter-GlobExporter] PR #1: 0.006 bump; Package tests


jplesnik merged a pull-request against the project: 
`perl-Sub-Exporter-GlobExporter` that you are following.

Merged pull-request:

``
0.006 bump; Package tests
``

https://src.fedoraproject.org/rpms/perl-Sub-Exporter-GlobExporter/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: Linking problem with ncurses on rawhide, not f37

* Miroslav Lichvar:

> On Mon, Jan 02, 2023 at 06:07:25PM +0100, Florian Weimer wrote:
>> * Miroslav Lichvar:
>> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
>> > `wmove@NCURSES6_5.0.19991023'
>> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
>> > `derwin@NCURSES6_5.0.19991023'
>> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
>> > `wenclose@NCURSES6_5.0.19991023'
>> > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
>> > `_nc_panelhook_sp@NCURSES6_5.8.20110226'
>> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
>> > `wcursyncup@NCURSES6_5.0.19991023'
>> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
>> > `copywin@NCURSES6_5.0.19991023'
>> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
>> > `newpad@NCURSES6_5.0.19991023'
>> > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
>> > `wnoutrefresh@NCURSES6_5.0.19991023'
>> > ...
>> >
>> > libform and libpanel depend on libncurses.
>> 
>> Could you give them a similar treatment, with more linker scripts?
>
> It doesn't work if I add AS_NEEDED(libpanel libform) to libncurses. It
> works if I add it to libtinfo. I guess that comes from the order of
> NEEDED in liblldb.so.13git, which is included in the linker command.
>
>   NEEDED   libtinfo.so.6
>   NEEDED   libncurses.so.6
>   NEEDED   libform.so.6
>   NEEDED   libpanel.so.6
>
> Would every ncurses library need to have all other libraries in
> AS_NEEDED?

Yeah, I think so.  I was worried about that.  Unfortunately, it doesn't
seem to be possible to set -rpath-link from a linker script.

> In any case, I don't like much the fact that with this approach it
> would be possible to link ncurses/panel/form applications using just
> -lncurses or -ltinfo. An application developed on Fedora might fail to
> build on other systems.

Yes, I think we need to wait until we have stub objects.  They avoid
this issue because they won't depend on anything.

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

[rpms/perl-HTTP-Daemon-SSL] PR #1: Fix for IO::Socket::SSL 2.078

2023-01-03 Thread Michal Josef Špaček


mspacek opened a new pull-request against the project: `perl-HTTP-Daemon-SSL` 
that you are following:
``
Fix for IO::Socket::SSL 2.078
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTTP-Daemon-SSL/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

[EPEL-devel] Re: libmaxminddb removed from epel7

2023-01-03 Thread Dan Horák

On Tue, 03 Jan 2023 11:12:02 -
"Sebastian Albrecht"  wrote:

> Hi friends
> i am using the epel(7) repo in Amazon Linux 2 and since two weeks ago the 
> package libmaxminddb disappeared. Is this the right place to ask for why it 
> was removed from the repository. Is there some kind of a removal announcement 
> / change history list?

I believe it was removed from EPEL-7, because it's available in RHEL-7,
added in 7.7 if I see right.


Dan
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmautospec - how to add suffix to the current release and don't bump it right now

On Tue, Jan 03, 2023 at 12:00:21PM +0100, Zdenek Dohnal wrote:
> Hi all,
> 
> I would like to ask a question about whether the workflow below, which I use
> frequently, can be used in packages which uses rpmautospec. I hit this when
> I was doing a testing scratch build of another package which already
> switched to rpmautospec and since rpmautospec is now proposed to be default
> for new packages, I would like to know whether, and if so, how my workflow
> can be applied with rpmautospec.
> 
> My workflow:
> 
> If I have a fix which I want to send to user to verify in its environment, I
> do a testing build, which has the same release as the current stable package
> (f.e. 1.fc37), but I add additional suffix to set the testing build to
> higher NVR than the package in the stable (f.e. 1.fc37.test.1). Then the
> user can just install the testing packages via DNF, accepting koji links to
> RPMs, and once an official fixed package arrives (with bumped NVR - 2.fc37),
> the official stable package replaces the testing one, ensuring the user has
> the supported rpms.
> 
> Is this doable with rpmautospec and if it is, how?

My understanding — which may be not be the whole picture — is that this is not
supported by rpmautospec natively. Essentially, every spec file change is
_supposed_ to caused the Release number to grow, so by definition, a commit that
adds a minorbump will also cause a bump of the release value, which is not
useful.

The desired effect can be implemented by overriding %dist:

  %global dist %dist~test.0
  Release: %autorelease

Notice that I used '~' to make the redefined %dist _lower_ than the original.
Let's say that the last official build had Release==1.
When this spec is built, you end up with Release==2.fc38~test.0.
When the %dist override is removed, and the package is built officially,
we end up with Release==2.fc38  (2.fc38~test.0 < 2.fc38).

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

[EPEL-devel] libmaxminddb removed from epel7

2023-01-03 Thread Sebastian Albrecht

Hi friends
i am using the epel(7) repo in Amazon Linux 2 and since two weeks ago the 
package libmaxminddb disappeared. Is this the right place to ask for why it was 
removed from the repository. Is there some kind of a removal announcement / 
change history list?

Thank you + BR,
Sebastian.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Linking problem with ncurses on rawhide, not f37

2023-01-03 Thread Miroslav Lichvar

On Mon, Jan 02, 2023 at 06:07:25PM +0100, Florian Weimer wrote:
> * Miroslav Lichvar:
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `wmove@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `derwin@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `wenclose@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
> > `_nc_panelhook_sp@NCURSES6_5.8.20110226'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `wcursyncup@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `copywin@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libform.so.6: undefined reference to 
> > `newpad@NCURSES6_5.0.19991023'
> > /usr/bin/ld: /usr/lib64/libpanel.so.6: undefined reference to 
> > `wnoutrefresh@NCURSES6_5.0.19991023'
> > ...
> >
> > libform and libpanel depend on libncurses.
> 
> Could you give them a similar treatment, with more linker scripts?

It doesn't work if I add AS_NEEDED(libpanel libform) to libncurses. It
works if I add it to libtinfo. I guess that comes from the order of
NEEDED in liblldb.so.13git, which is included in the linker command.

  NEEDED   libtinfo.so.6
  NEEDED   libncurses.so.6
  NEEDED   libform.so.6
  NEEDED   libpanel.so.6

Would every ncurses library need to have all other libraries in
AS_NEEDED?

In any case, I don't like much the fact that with this approach it
would be possible to link ncurses/panel/form applications using just
-lncurses or -ltinfo. An application developed on Fedora might fail to
build on other systems.

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

rpmautospec - how to add suffix to the current release and don't bump it right now

2023-01-03 Thread Zdenek Dohnal


Hi all,

I would like to ask a question about whether the workflow below, which I 
use frequently, can be used in packages which uses rpmautospec. I hit 
this when I was doing a testing scratch build of another package which 
already switched to rpmautospec and since rpmautospec is now proposed to 
be default for new packages, I would like to know whether, and if so, 
how my workflow can be applied with rpmautospec.


My workflow:

If I have a fix which I want to send to user to verify in its 
environment, I do a testing build, which has the same release as the 
current stable package (f.e. 1.fc37), but I add additional suffix to set 
the testing build to higher NVR than the package in the stable (f.e. 
1.fc37.test.1). Then the user can just install the testing packages via 
DNF, accepting koji links to RPMs, and once an official fixed package 
arrives (with bumped NVR - 2.fc37), the official stable package replaces 
the testing one, ensuring the user has the supported rpms.


Is this doable with rpmautospec and if it is, how?

Thank you in advance!


Zdenek

--
Zdenek Dohnal
Software Engineer
Red Hat, BRQ-TPBC
___
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 2157860] New: perl-CGI-4.55 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157860

Bug ID: 2157860
   Summary: perl-CGI-4.55 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CGI
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
mspa...@redhat.com, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 4.55
Upstream release that is considered latest: 4.55
Current version/release in rawhide: 4.54-4.fc37
URL: http://search.cpan.org/dist/CGI/

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/2687/


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157860
___
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: 20230103.n.0 changes

2023-01-03 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20230102.n.0
NEW: Fedora-Rawhide-20230103.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  4
Dropped packages:0
Upgraded packages:   92
Downgraded packages: 0

Size of added packages:  1.04 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.85 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20230102.n.0.iso

= ADDED PACKAGES =
Package: rust-rxml_proc-0.8.2-1.fc38
Summary: Macros to perform compile-time XML string validations
RPMs:rust-rxml_proc+default-devel rust-rxml_proc-devel
Size:17.74 KiB

Package: rust-weak-table-0.3.2-1.fc38
Summary: Weak hash maps and sets
RPMs:rust-weak-table+ahash-devel rust-weak-table+alloc-devel 
rust-weak-table+default-devel rust-weak-table+std-devel rust-weak-table-devel
Size:61.75 KiB

Package: usbrelay-1.1.2-1.fc38
Summary: A library and command line tool to control USB-connected relays based 
on hidapi
RPMs:python3-usbrelay-py usbrelay usbrelay-devel usbrelay-mqtt
Size:275.75 KiB

Package: xbyak_aarch64-1.0.0-6.fc38
Summary: JIT assembler for AArch64 CPUs by C++
RPMs:xbyak_aarch64 xbyak_aarch64-devel xbyak_aarch64-static
Size:709.85 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  BackupPC-XS-0.62-10.fc38
Old package:  BackupPC-XS-0.62-9.fc37
Summary:  Implementation of various BackupPC functions in a perl-callable 
module
RPMs: BackupPC-XS
Size: 433.75 KiB
Size change:  -1 B
Changelog:
  * Mon Jan 02 2023 Florian Weimer  - 0.62-10
  - Port configure script to C99


Package:  BlockOutII-2.5-22.fc38
Old package:  BlockOutII-2.5-21.fc37
Summary:  A free adaptation of the original BlockOut DOS game
RPMs: BlockOutII
Size: 16.33 MiB
Size change:  439 B
Changelog:
  * Mon Jan 02 2023 Florian Weimer  - 2.5-22
  - C99 compatibility fix (#2157594)


Package:  RBTools-4.0-1.fc38
Old package:  RBTools-3.1.1-1.fc38
Summary:  Tools for use with ReviewBoard
RPMs: RBTools
Size: 902.53 KiB
Size change:  181.74 KiB
Changelog:
  * Mon Jan 02 2023 Jonathan Wright - 3.1.2-1
  - Update to 3.1.2
  - Fix for python 3.11

  * Mon Jan 02 2023 Jonathan Wright - 4.0-1
  - Update to 4.0


Package:  aime-8.20221204-1.fc38
Old package:  aime-8.20221121-1.fc38
Summary:  An application embeddable programming language interpreter
RPMs: aime aime-devel
Size: 3.65 MiB
Size change:  5.24 KiB
Changelog:
  * Tue Jan 03 2023 Filipe Rosset  - 8.20221204-1
  - Update to 8.20221204 fixes rhbz#2150732


Package:  arch-install-scripts-28-1.fc38
Old package:  arch-install-scripts-27-1.fc38
Summary:  Scripts to bootstrap Arch Linux distribution
RPMs: arch-install-scripts
Size: 28.98 KiB
Size change:  318 B
Changelog:
  * Mon Jan 02 2023 jonathanspw  28-1
  - update to v28 rhbz#2144286


Package:  arm-none-eabi-binutils-cs-1:2.39-2.fc38
Old package:  arm-none-eabi-binutils-cs-1:2.39-1.fc38
Summary:  GNU Binutils for cross-compilation for arm-none-eabi target
RPMs: arm-none-eabi-binutils-cs
Size: 9.83 MiB
Size change:  -55.11 KiB
Changelog:
  * Mon Jan 02 2023 Florian Weimer  - 1:2.39-2
  - C99 compatibility fixes for the configure script


Package:  bash-5.2.15-1.fc38
Old package:  bash-5.2.9-3.fc38
Summary:  The GNU Bourne Again shell
RPMs: bash bash-devel bash-doc
Size: 13.45 MiB
Size change:  23.17 KiB
Changelog:
  * Fri Nov 18 2022 Siteshwar Vashisht  - 5.2.9-1
  - Update to bash-5.2 patchlevel 9
Resolves: #2140722

  * Fri Nov 18 2022 Siteshwar Vashisht  - 5.2.9-2
  - Fix binary file detection
Resolves: #2135537

  * Fri Nov 18 2022 Debarshi Ray  - 5.2.9-3
  - Override STANDARD_UTILS_PATH in the same way as DEFAULT_PATH_VALUE
Related: #2132363

  * Mon Jan 02 2023 Siteshwar Vashisht  - 5.2.15-1
  - Update to bash-5.2 patchlevel 15
Resolves: #2152991


Package:  blosc-1.21.2-1.fc38
Old package:  blosc-1.21.1-3.fc37
Summary:  High performance compressor optimized for binary data
RPMs: blosc blosc-bench blosc-devel
Size: 426.98 KiB
Size change:  -17.26 KiB
Changelog:
  * Mon Jan 02 2023 jonathanspw  1.21.2-1
  - update to 1.21.2 rhbz#2152010


Package:  bpfmon-2.51-1.fc38
Old package:  bpfmon-2.50-3.fc37
Summary:  Traffic monitor for BPF expression/iptables rule
RPMs: bpfmon
Size: 127.56 KiB
Size change:  -1.56 KiB

Package:  chromium-108.0.5359.124-2.fc38
Old package:  chromium-108.0.5359.124-1.fc38
Summary:  A WebKit (Blink) powered web browser that Google doesn't want you 
to use
RPMs: chromedriver chromium chromium-common chromium-headless
Added RPMs:   chromium-headless
Size: 262.67 MiB

[Bug 2157235] perl-CPAN-Uploader-0.103017 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157235

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|iarn...@gmail.com,  |
   |jples...@redhat.com |
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157235
___
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: Schedule for Tuesday's FESCo Meeting (2023-01-03)

On Tue, Jan 03, 2023 at 10:39:13AM +0100, Miro Hrončok wrote:
> = Discussed and Voted in the Ticket =
…
> Change: Use mdadm for BIOS RAID Support in Anaconda
> https://pagure.io/fesco/issue/2922

Something went wrong here. The tally is +4,0,0 on this one.
The ticket wasn't closed.

Zbyszek
___
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: Schedule for Tuesday's FESCo Meeting (2023-01-03)


On 03. 01. 23 10:39, Miro Hrončok wrote:

Change: Use mdadm for BIOS RAID Support in Anaconda
https://pagure.io/fesco/issue/2922


A decision has not yet been made officially for this one, I copy pasted it to 
the email and forgot to remove it before I sent it. Sorry about that.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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-Sub-Exporter-GlobExporter] PR #1: 0.006 bump; Package tests


jplesnik opened a new pull-request against the project: 
`perl-Sub-Exporter-GlobExporter` that you are following:
``
0.006 bump; Package tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Sub-Exporter-GlobExporter/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: Schedule for Tuesday's FESCo Meeting (2023-01-03)


On 03. 01. 23 10:39, Miro Hrončok wrote:

Title of issue
https://pagure.io/fesco/issue/###
DECISION (+X, Y, -Z)


There was no actual issue supposed to be listed here instead of the 
placeholder, it was merely redundant.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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

Schedule for Tuesday's FESCo Meeting (2023-01-03)


Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2023-01-03 17:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Title of issue
https://pagure.io/fesco/issue/###
DECISION (+X, Y, -Z)

Change: Strong crypto settings: phase 3, forewarning 2/2
https://pagure.io/fesco/issue/2865
REJECTED (+1, 4, 0)

Non-responsive maintainer: miminar / Michal Minar
https://pagure.io/fesco/issue/2891
APPROVED (+4,0,-0)

Change: Perl: Replace versioned MODULE_COMPAT_ requires by RPM dependency 
generator
https://pagure.io/fesco/issue/2898
APPROVED (+2, 0, -0)

Nonresponsive maintainer: Steven Roberts strobert
https://pagure.io/fesco/issue/2902
APPROVED (+2, 0, -0)

Change: Golang 1.20
https://pagure.io/fesco/issue/2913
APPROVED (+6, 0, -0)

Change: Fedora Sway Spin
https://pagure.io/fesco/issue/2914
APPROVED (+6, 0, -0)

Change: libpinyin 2.8
https://pagure.io/fesco/issue/2915
APPROVED (+6, 0, -0)

Change: GNU Make version 4.4
https://pagure.io/fesco/issue/2916
APPROVED (+5, 0, -0)

Change: Add _FORTIFY_SOURCE=3 to distribution build flags
https://pagure.io/fesco/issue/2917
APPROVED: (+5, 0, 0)

Change: Boost 1.81 upgrade
https://pagure.io/fesco/issue/2918
APPROVED (+7, 0, -0)

Change: Restore stricter SSH hostkeys permissions
https://pagure.io/fesco/issue/2919
APPROVED (+4, 0, -0)

Change: ImageMagick 7
https://pagure.io/fesco/issue/2920
APPROVED (+6, 0, -0)

Change: Fedora Budgie Spin
https://pagure.io/fesco/issue/2921
APPROVED (+5, 0, -0)

Change: Use mdadm for BIOS RAID Support in Anaconda
https://pagure.io/fesco/issue/2922


= New business =

#2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to default 
compilation flags

https://pagure.io/fesco/issue/2923


= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Kalev Lember

On Tue, Jan 3, 2023 at 10:13 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> > On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > > - fedpkg mockbuild
> >
> > But it doesn't work correctly (will always use Release: 1) if you run
> > "rpmbuild -bs foo-bar.spec" which is a very common scenario.
>
> "Doctor, it hurts when I do that."
>
> 'rpmbuild -bs' is broken. Don't use it.
>

Yes, I would say that as well. It's just a low level tool and can never
have all the integration with git that fedpkg has.

We might need to update package maintainer documents to be clear about this
though, so that people know that they should use 'fedpkg srpm' and not
'rpmbuild -bs'.

-- 
Kalev
___
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 2157228] perl-Sub-Exporter-GlobExporter-0.006 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157228

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|iarn...@gmail.com,  |
   |jples...@redhat.com |
   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157228
___
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 2157226] perl-String-Formatter-1.235 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157226

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-String-Formatter-1.235
   ||-1.fc38
 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2023-01-03 09:12:50




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157226
___
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Tue, Jan 03, 2023 at 09:32:58AM +0100, Vitaly Zaitsev via devel wrote:
> On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:
> > - fedpkg mockbuild
> 
> But it doesn't work correctly (will always use Release: 1) if you run
> "rpmbuild -bs foo-bar.spec" which is a very common scenario.

"Doctor, it hurts when I do that."

'rpmbuild -bs' is broken. Don't use it.

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

License change - python-flask-whooshee

2023-01-03 Thread Miroslav Suchý


The package python-flask-whooshee changed license from GPLv2+ to BSD-3-Clause.

The change actually happened in upstream after version 0.3.0 (and we have now 
0.8.2).

Miroslav
___
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: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

2023-01-03 Thread Peter Boy



> Am 30.12.2022 um 19:45 schrieb Nico Kadel-Garcia :
> 
> We need to be cautious about
> not being able to personally picture why someone would use an existing
> default and overriding it casually, and inflicting our new logic on
> the unsuspecting existing userbase.

+1!




--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast


___
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: Orphaned packages looking for new maintainers



Dne 03. 01. 23 v 9:37 Vít Ondruch napsal(a):


Dne 03. 01. 23 v 1:45 Maxwell G via devel napsal(a):

On Mon Jan 2, 2023 at 11:46 -0600, Robby Callicotte via devel wrote:

I went ahead and took vim-nerdtree.



Oh, I have noticed vim-nerdtree was orpahned. But it is not 
surprising, since all Slavek's packages were. Thank you for picking it 
up.





FYI: Nerdtree is unmaintained upstream:
https://github.com/preservim/nerdtree/issues/1280



:(



Has anybody tried https://github.com/lambdalisue/fern.vim as an 
replacement? Or any other suggestion, ideally if they have been packaged 
already.



Thx


Vít





V.




--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
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


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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Vitaly Zaitsev via devel


On 03/01/2023 09:30, Petr Pisar wrote:

Different number of commits will mean different release numbers. That will
break package interdependencies which requires a specific release number. E.g
foo requires bar.


Good point. Hard-coded release numbers are a serious problem even in Fedora.

We have a serious issue with mesa vs. mesa-freeworld synchronization, 
because Fedora's mesa package has a strict EVR dependency requirement. 
RPM Fusion maintainers can't even bump Release, otherwise the package 
can't be installed due to conflict[1].


[1]: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426

--
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: Orphaned packages looking for new maintainers



Dne 03. 01. 23 v 1:45 Maxwell G via devel napsal(a):

On Mon Jan 2, 2023 at 11:46 -0600, Robby Callicotte via devel wrote:

I went ahead and took vim-nerdtree.



Oh, I have noticed vim-nerdtree was orpahned. But it is not surprising, 
since all Slavek's packages were. Thank you for picking it up.





FYI: Nerdtree is unmaintained upstream:
https://github.com/preservim/nerdtree/issues/1280



:(


V.




--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
___
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


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

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Vitaly Zaitsev via devel


On 01/01/2023 15:10, Florian Weimer wrote:

COPR seems to work in some cases, specifically with the dist-git build
(but not just building from dist-git).


Run "rpmbuild -bs foo-bar.spec", upload it to COPR and it will use 
Release: 1.


I also need to figure out if it works with building from SCM without 
uploading rendered SRPM.


--
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Vitaly Zaitsev via devel


On 02/01/2023 21:44, Zbigniew Jędrzejewski-Szmek wrote:

- fedpkg mockbuild


But it doesn't work correctly (will always use Release: 1) if you run 
"rpmbuild -bs foo-bar.spec" which is a very common scenario.


--
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: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

2023-01-03 Thread Petr Pisar

V Fri, Dec 30, 2022 at 02:10:52PM -0500, Neal Gompa napsal(a):
> Have we made sure that when Red Hat forks Fedora packages for RHEL
> that they don't truncate or eliminate the Git history anymore? Because I would
> personally be very displeased if my historical attribution went away
> because of broken processes like the one used to fork all the Fedora
> Linux 34 packages for CentOS Stream 9.
> 
It's not only about loosing attributions. There will be NEVRA discrepancies in
RHEL:

Different number of commits will mean different release numbers. That will
break package interdependencies which requires a specific release number. E.g
foo requires bar. Fedora bar-1-2 contains a vital fix for foo. Thus Fedora foo
will strengthen the dependency with "Requires: bar >= 1-2". However, after
importing to RHEL, bar will become bar-1-1. The dependency from foo will
break.

Another RHEL problem will be fixes for minor RHEL version. E.g. RHEL 10.0 will
contain foo-1-1, RHEL-10.1 updates to foo-1-2, then RHEL-10.0 backports
the change, preferably as foo-1-1.el10_0.1. However, the generated rpmautospec
schema won't allow it and will produce foo-1-2.el10_0. I foresee RHEL
maintainers to revert rpmautospec to manual numbering for minor RHEL updates.

None of these issues are Fedora issues. But considering the ecosystems
wholistically, the proposed rpmautospec propotion will add a friction.

-- Petr




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 2157226] perl-String-Formatter-1.235 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2157226

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|iarn...@gmail.com,  |
   |jples...@redhat.com |
 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2157226
___
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 2157225] perl-String-Errf-0.009 is available