Re: Adoption of flare package

[Otto Liljalaakso]

Sandro kirjoitti 25.8.2022 klo 1.05:


On 8/24/22 23:43, Otto Liljalaakso wrote:


It looks like a commit was queuing in a pull request for a long time,
then merged after other things had happened in rawhide. Probably a more
correct Git date to use in %changelog would be the commit date instead
of author date:

$  git log --pretty=fuller -n 1 fffbc90b
commit fffbc90bcf7a79f918d6ee7f34dfdc43042967c6
Author: Justin Jacobs 
AuthorDate: Tue Oct 12 18:31:17 2021 -0400
Commit: Erik Schilling 
CommitDate: Tue Feb 1 19:42:45 2022 +0100

  Update to 1.12 and fix font symlinks

The date when the release happened is good, too.


Well, the release never happened. In flare's spec file it is not 
present. According to koji[1] it went from 1.07 straight to 1.13. Same 
for flare.


So, I decided to just remove the changelog entry entirely.


Thank you, that is a good solution.
___
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: Users with commit rights in src.fp.o but no more in packager group

[Miro Hrončok]

On 24. 08. 22 22:53, Alasdair G Kergon wrote:

On Wed, Aug 24, 2022 at 09:50:59PM +0200, Fabio Valentini wrote:

I think some of those *-team / *-sig / *-maint pseudo-group users are
outdated. Most of them probably pre-date the existence of actual
groups, so they are probably all ancient. For example, we removed the
xgl-maint pseudo-group a while ago, because it was actually unused,
and its associated bugzilla account was disabled.
I wonder for how many of these groups the same is true, and whether we
should actually remove them from all packages where that's the case.
  
lvm-team is still in use as a package owner and default bugzilla

assignee.  To do anything of any significance using the account, we were
instructed to open a ticket to ask for the change to be made for us.

It has never been a member of the packager group because it was
decided that accounts that are not individuals cannot sign the
legal agreement that is a pre-requisite to being able to join that
group.


We use the python-maint pseudo-account to be the default Bugzilla assignee for 
Pythons, e.g. https://src.fedoraproject.org/rpms/python3.11


Note that it does *not* require the account to be listed in maintainers or to 
have commit rights.


--
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: Ruby FTBFS due to "SHA-1 jump scare"

[Miro Hrončok]

On 24. 08. 22 16:58, Alexander Sosedkin wrote:

On Wed, Aug 24, 2022 at 4:33 PM Alexander Sosedkin  wrote:


On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini  wrote:


On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin  wrote:


On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch  wrote:


Alexander,

Would you mind to comment on your intentions with:

https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide

which just landed in Fedora and broke Ruby test suite (even more then it
was broken before):

https://koschei.fedoraproject.org/package/ruby

Although I know something like this was discussed and is already enabled
in c9s,


Yes, it was: [2], [3]


I am not aware that the associated change [1] would be approved
nor that you would send a warning that this is going to happen.


Wait, right. It was just the Forewarning1 [4] that was approved,
not the Forewarning2 one.


Am I missing something?


My intention was to break it right at the branch-off.
What do I do now? Just keep it as it is?
Revert, somehow initiate the approval early and unrevert once I have one?


I don't think keeping rawhide/f38 intentionally broken, even if you're
going to revert the brokenness in f38 after it branches off, is ever a
good idea.
Please revert the change and wait for the devel list and FESCo
discussion of the topic before implementing it again.


Ack, will do promptly. My bad.


Reverted in crypto-policies-20220824-2.git2187e9c.fc38,
sorry for the premature jump scare.


Hey Alexander,

In the meantime, have you considered doing this in Copr and rebuilding 
everything there, to have some statistics about impacted packages, before the 
change is discussed?


--
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: abipkgdiff - indirect sub-type changes

[Orion Poplawski]

On 8/24/22 04:07, Kevin Kofler via devel wrote:

Orion Poplawski wrote:

Does this break ABI?


Yes. They changed functions to take 64-bit integers instead of 32-bit ones.
When called by code compiled against a previous version, the upper half will
be garbage. On some architectures (depending on how exactly arguments are
passed, but they will usually be big-endian ones), even the whole thing.
(There, the lower half will be complete garbage, and the upper half will be
what should be the lower half. Or in the worst case, some architectures
might even decide to switch from register to stack passing, making the whole
number or even also the other arguments complete garbage.)

 Kevin Kofler


Thank you - I thought as much but nice to have some confirmation.  I've 
reported it upstream.


--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic 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

[EPEL-devel] Re: [new / help wanted] fence-agents-epel package

[Alex Talaran]

i dont need them but wasnt sure if required for epel to keep things 
complete and similar to the base package. how did you want me to change 
the names? i left it the same as in the original spec file, and named 
this one -epel after previous discussion on list


On 2022-08-24 17:13, Troy Dawson wrote:
I'm sure having all the fence agents in one package is nice for you, but 
if someone has both Fedora and RHEL based machines, they would 
appreciate the packages having the same naming conventions.

This is looking pretty good.
I'll do some poking about for the man pages.  How badly do you want the 
man pages?


Troy


On Tue, Aug 23, 2022 at 6:40 AM Alex Talaran > wrote:


attached a new spec using 4.10 which should match el9 (desired distro
version) as you noted.
srpm and rpm still seem to build fine without man pages, still not sure
how to generate them.

On 2022-08-08 17:22, Troy Dawson wrote:
 > Hi Alex,
 > I've been looking into this some.
 >
 > What distribution do you want this for?
 > I haven't seen anywhere in your emails saying if this is for RHEL
8 or
 > RHEL 9?
 > The spec file you have attached is for fence-agents-4.11, which
is only
 > in Fedora, so that doesn't let me know either.
 >
 > The major problem is that the fence-agents-pve version has to
match the
 > fence-agents that is in your version of RHEL.
 > So for RHEL8 (or compatible) it needs to be version 4.2.1.  For
RHEL 9
 > it needs to be 4.10.0
 >
 > We need to start with the correct version of fence-agents and
work from
 > there.
 >
 > Troy
 >
 > On Wed, Jul 27, 2022 at 10:03 AM Alex Talaran mailto:atala...@gmail.com>
 > >> wrote:
 >
 >     i was able to get this built and installable if anyone wants
to help
 >     test or maintain it.
 >     an issue exists with the man pages not being built still but
im not
 >     sure
 >     how the makefile target works for these so they are excluded
for now.
 >
 >     maybe some other small tweaks are still needed too since its
just a
 >     (first for me) stripped down and modified upstream spec file.
 >
 >     On 2022-07-20 08:47, Andrew C Aitchison wrote:
 >      > On Wed, 20 Jul 2022, Alex Talaran wrote:
 >      >
 >      >> i ended up with the same error with that change.
 >      >
 >      > I am sorry my suggestion did not help.
 >      > I don't have a Red Hat compatible machine newer that RHEL6
 >      > (I moved to Ubuntu for work-related reasons)
 >      > so I am unable to test things myself.
 >      >
 >      >> is it possible its getting confused because the dirname
in the
 >     tarball
 >      >> is different than the package name and looking in the
wrong spot?
 >      >
 >      > The -n fence-agents-%{version} in
 >      >  %prep
 >      >  %setup -q -n fence-agents-%{version}
 >      > is supposed to resolve that, but that setup line might
need tweaking
 >      > to match the contents of the tarball.
 >      >
 >      > It is old and may be somewhat dated, but my bible for
rewriting
 >     .spec
 >      > files was the book
 >      >     Maximum RPM - Taking the Red Hat Package Manager to
the Limit
 >      > a version of which is available at
 >      > http://ftp.rpm.org/max-rpm/index.html

 >     >
 >      >
 >      >> On 2022-07-19 23:32, Andrew C Aitchison wrote:
 >      >>> On Tue, 19 Jul 2022, Alex Talaran wrote:
 >      >>>
 >       per a previous thread i took a shot at cleaning up the
 >     fence-agents
 >       rpm to only include the missing agents and make a new
package.
 >     i am
 >       having some issues with the source url and getting it to
 >     build. the
 >       srpm is ok, but when i try to rebuild it into a proper
rpm i
 >     get the
 >       following (output truncated):
 >      
 >       ---
 >       + py39_byte_compile /usr/bin/python3
 >      
 >   
  /builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence

 >       + python_binary='env PYTHONHASHSEED=0 /usr/bin/python3'
 >       +
 >      
 >   
  bytecode_compilation_path=/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence

 >       + env PYTHONHASHSEED=0 /usr/bin/python3 -s -B -m
compileall -o
 >     0 -o
 >       1 -s
 >     /builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64
 >       -p /
 >      
 >   
  

[EPEL-devel] Re: [new / help wanted] fence-agents-epel package

[Troy Dawson]

I'm sure having all the fence agents in one package is nice for you, but if
someone has both Fedora and RHEL based machines, they would appreciate the
packages having the same naming conventions.
This is looking pretty good.
I'll do some poking about for the man pages.  How badly do you want the man
pages?

Troy


On Tue, Aug 23, 2022 at 6:40 AM Alex Talaran  wrote:

> attached a new spec using 4.10 which should match el9 (desired distro
> version) as you noted.
> srpm and rpm still seem to build fine without man pages, still not sure
> how to generate them.
>
> On 2022-08-08 17:22, Troy Dawson wrote:
> > Hi Alex,
> > I've been looking into this some.
> >
> > What distribution do you want this for?
> > I haven't seen anywhere in your emails saying if this is for RHEL 8 or
> > RHEL 9?
> > The spec file you have attached is for fence-agents-4.11, which is only
> > in Fedora, so that doesn't let me know either.
> >
> > The major problem is that the fence-agents-pve version has to match the
> > fence-agents that is in your version of RHEL.
> > So for RHEL8 (or compatible) it needs to be version 4.2.1.  For RHEL 9
> > it needs to be 4.10.0
> >
> > We need to start with the correct version of fence-agents and work from
> > there.
> >
> > Troy
> >
> > On Wed, Jul 27, 2022 at 10:03 AM Alex Talaran  > > wrote:
> >
> > i was able to get this built and installable if anyone wants to help
> > test or maintain it.
> > an issue exists with the man pages not being built still but im not
> > sure
> > how the makefile target works for these so they are excluded for now.
> >
> > maybe some other small tweaks are still needed too since its just a
> > (first for me) stripped down and modified upstream spec file.
> >
> > On 2022-07-20 08:47, Andrew C Aitchison wrote:
> >  > On Wed, 20 Jul 2022, Alex Talaran wrote:
> >  >
> >  >> i ended up with the same error with that change.
> >  >
> >  > I am sorry my suggestion did not help.
> >  > I don't have a Red Hat compatible machine newer that RHEL6
> >  > (I moved to Ubuntu for work-related reasons)
> >  > so I am unable to test things myself.
> >  >
> >  >> is it possible its getting confused because the dirname in the
> > tarball
> >  >> is different than the package name and looking in the wrong spot?
> >  >
> >  > The -n fence-agents-%{version} in
> >  >  %prep
> >  >  %setup -q -n fence-agents-%{version}
> >  > is supposed to resolve that, but that setup line might need
> tweaking
> >  > to match the contents of the tarball.
> >  >
> >  > It is old and may be somewhat dated, but my bible for rewriting
> > .spec
> >  > files was the book
> >  > Maximum RPM - Taking the Red Hat Package Manager to the Limit
> >  > a version of which is available at
> >  > http://ftp.rpm.org/max-rpm/index.html
> > 
> >  >
> >  >> On 2022-07-19 23:32, Andrew C Aitchison wrote:
> >  >>> On Tue, 19 Jul 2022, Alex Talaran wrote:
> >  >>>
> >   per a previous thread i took a shot at cleaning up the
> > fence-agents
> >   rpm to only include the missing agents and make a new package.
> > i am
> >   having some issues with the source url and getting it to
> > build. the
> >   srpm is ok, but when i try to rebuild it into a proper rpm i
> > get the
> >   following (output truncated):
> >  
> >   ---
> >   + py39_byte_compile /usr/bin/python3
> >  
> >
>  
> /builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence
> >   + python_binary='env PYTHONHASHSEED=0 /usr/bin/python3'
> >   +
> >  
> >
>  
> bytecode_compilation_path=/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence
> >   + env PYTHONHASHSEED=0 /usr/bin/python3 -s -B -m compileall -o
> > 0 -o
> >   1 -s
> > /builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64
> >   -p /
> >  
> >
>  
> /builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence
> >   Listing
> >  
> >
>  
> '/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence'...
> >   Can't list
> >  
> >
>  
> '/builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence'
> >   + chmod 0755
> >  
> >
>  
> /builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_pve.py
> /builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_raritan.py
> /builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_rcd_serial.py
> /builddir/build/BUILDROOT/fence-agents-epel-4.11.0-1.el9.x86_64/usr/share/fence/fence_virsh.py
> >   chmod: cannot access
> >  
> >
>  

Re: Adoption of flare package

[Sandro]

On 8/24/22 23:43, Otto Liljalaakso wrote:

Sandro kirjoitti 24.8.2022 klo 23.50:


Yes, after I talked to him he became aware of the dependency between the
two packages and adopted flare as well.

AFAIK, both packages have been updated to the latest upstream release
now and built successfully. They should find their way into the
different repos, soon.


Great!





It looks like a commit was queuing in a pull request for a long time,
then merged after other things had happened in rawhide. Probably a more
correct Git date to use in %changelog would be the commit date instead
of author date:

$  git log --pretty=fuller -n 1 fffbc90b
commit fffbc90bcf7a79f918d6ee7f34dfdc43042967c6
Author: Justin Jacobs 
AuthorDate: Tue Oct 12 18:31:17 2021 -0400
Commit: Erik Schilling 
CommitDate: Tue Feb 1 19:42:45 2022 +0100

  Update to 1.12 and fix font symlinks

The date when the release happened is good, too.


Well, the release never happened. In flare's spec file it is not 
present. According to koji[1] it went from 1.07 straight to 1.13. Same 
for flare.


So, I decided to just remove the changelog entry entirely.

[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=18939

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

Fedora 37 compose report: 20220824.n.2 changes

[Fedora Rawhide Report]

OLD: Fedora-37-20220823.n.0
NEW: Fedora-37-20220824.n.2

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  0
Dropped packages:21
Upgraded packages:   17
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:1.32 MiB
Size of upgraded packages:   456.86 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-37-20220823.n.0.aarch64.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: dbxtool-8-15.fc35
Summary: Secure Boot DBX updater
RPMs:dbxtool
Size:68.01 KiB

Package: perl-Clone-0.45-9.module_f37+14883+b73fbf84
Summary: Recursively copy perl data types
RPMs:perl-Clone
Size:87.13 KiB

Package: perl-Data-Dump-1.25-5.module_f37+14883+b73fbf84
Summary: Pretty printing of data structures
RPMs:perl-Data-Dump
Size:33.57 KiB

Package: perl-Digest-HMAC-1.04-6.module_f37+14883+b73fbf84
Summary: Keyed-Hashing for Message Authentication
RPMs:perl-Digest-HMAC perl-Digest-HMAC-tests
Size:35.56 KiB

Package: perl-Encode-Locale-1.05-24.module_f37+14883+b73fbf84
Summary: Determine the locale encoding
RPMs:perl-Encode-Locale
Size:18.87 KiB

Package: perl-File-Listing-6.15-3.module_f37+14883+b73fbf84
Summary: Parse directory listing
RPMs:perl-File-Listing perl-File-Listing-tests
Size:58.78 KiB

Package: perl-HTML-Parser-3.78-3.module_f37+14883+b73fbf84
Summary: Perl module for parsing HTML
RPMs:perl-HTML-Parser
Size:478.42 KiB

Package: perl-HTML-Tagset-3.20-52.module_f37+14883+b73fbf84
Summary: HTML::Tagset - data tables useful in parsing HTML
RPMs:perl-HTML-Tagset
Size:18.75 KiB

Package: perl-HTTP-Cookies-6.10-7.module_f37+14883+b73fbf84
Summary: HTTP cookie jars
RPMs:perl-HTTP-Cookies
Size:37.66 KiB

Package: perl-HTTP-Date-6.05-10.module_f37+14883+b73fbf84
Summary: Date conversion routines
RPMs:perl-HTTP-Date
Size:23.91 KiB

Package: perl-HTTP-Negotiate-6.01-33.module_f37+14883+b73fbf84
Summary: Choose a variant to serve
RPMs:perl-HTTP-Negotiate
Size:19.77 KiB

Package: perl-IO-HTML-1.004-7.module_f37+14883+b73fbf84
Summary: Open an HTML file with automatic character set detection
RPMs:perl-IO-HTML
Size:27.93 KiB

Package: perl-LWP-MediaTypes-6.04-12.module_f37+14883+b73fbf84
Summary: Guess media type for a file or a URL
RPMs:perl-LWP-MediaTypes
Size:33.21 KiB

Package: perl-LWP-Protocol-https-6.10-7.module_f37+14883+b73fbf84
Summary: Provide HTTPS support for LWP::UserAgent
RPMs:perl-LWP-Protocol-https
Size:21.31 KiB

Package: perl-Mozilla-CA-20211001-4.module_f37+14883+b73fbf84
Summary: Mozilla's CA certificate bundle in PEM format
RPMs:perl-Mozilla-CA
Size:12.39 KiB

Package: perl-NTLM-1.09-33.module_f37+14883+b73fbf84
Summary: NTLM Perl module
RPMs:perl-NTLM
Size:21.95 KiB

Package: perl-Net-HTTP-6.22-3.module_f37+14883+b73fbf84
Summary: Low-level HTTP connection (client)
RPMs:perl-Net-HTTP
Size:40.12 KiB

Package: perl-TimeDate-1:2.33-9.module_f37+14883+b73fbf84
Summary: A Perl module for time and date manipulation
RPMs:perl-TimeDate
Size:50.88 KiB

Package: perl-Try-Tiny-0.31-4.module_f37+14883+b73fbf84
Summary: Minimal try/catch with proper localization of $@
RPMs:perl-Try-Tiny
Size:37.69 KiB

Package: perl-WWW-RobotRules-6.02-33.module_f37+14883+b73fbf84
Summary: Database of robots.txt-derived permissions
RPMs:perl-WWW-RobotRules
Size:20.14 KiB

Package: perl-libwww-perl-6.67-2.module_f37+14883+b73fbf84
Summary: A Perl interface to the World-Wide Web
RPMs:perl-libwww-perl
Size:202.84 KiB


= UPGRADED PACKAGES =
Package:  avocado-vt-98.0-2.module_f37+15110+1083543c
Old package:  avocado-vt-90.0-1.module_f37+14041+73823c5b
Summary:  Avocado Virt Test Plugin
RPMs: python3-avocado-vt
Size: 9.10 MiB
Size change:  861.72 KiB
Changelog:
  * Mon Aug 30 2021 Cleber Rosa  - 91.0-1
  - New release

  * Tue Oct 19 2021 Cleber Rosa  - 92.0-1
  - New release

  * Wed Nov 17 2021 Cleber Rosa  - 93.0-1
  - New release

  * Mon Dec 20 2021 Cleber Rosa  - 94.0-1
  - New release

  * Thu Jul 14 2022 Cleber Rosa  - 98.0-1
  - New release

  * Thu Aug 18 2022 Lily Nie  - 98.0-2
  - Modify the code for Fedora


Package:  ceph-2:17.2.3-5.fc37
Old package:  ceph-2:17.2.3-4.fc37
Summary:  User space components of the Ceph file system
RPMs: ceph ceph-base ceph-common ceph-fuse ceph-grafana-dashboards 
ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm 
ceph-mgr-dashboard ceph-mgr-diskprediction-local ceph-mgr-k8sevents 
ceph-mgr-modules-core ceph-mgr-rook ceph-mon ceph-osd ceph-prometheus-alerts 
ceph-radosgw ceph-resource-agents ceph-selinux ceph-test ceph-volume cephadm 
cephfs-java cephfs-mirror cephfs-shell

Re: Adoption of flare package

[Otto Liljalaakso]

Sandro kirjoitti 24.8.2022 klo 23.50:


Yes, after I talked to him he became aware of the dependency between the 
two packages and adopted flare as well.


AFAIK, both packages have been updated to the latest upstream release 
now and built successfully. They should find their way into the 
different repos, soon.


Great!


However, one part of the cause of that problem is the trailing dot in
the end of '%cmake' [2]. It would be good to remove that. Since you are
interested in starting with package maintenance, that could be a good
first pull request for you.


I'll do that. I'm still in the process of getting acquainted. I tried to 
fork flare and flare-engine earlier, but wasn't able to. Seems like it 
was a temporary issue. Just tried again and it worked.


Anonymous forking in src.fedoraproject.org is a bit tricky to setup and 
use, great to hear that you got it working.



Building flare-engine also prints out another (non-fatal) error, you
could also correct that in a pull request, just for practice:

error: %changelog not in descending chronological order


I saw that when linting. Wasn't sure how to handle that. The offending 
changelog entry has the right date according to git blame. The releases 
are in the right order. Probably just adjust the date to when that 
release actually happened and silence rpmlint...


It looks like a commit was queuing in a pull request for a long time, 
then merged after other things had happened in rawhide. Probably a more 
correct Git date to use in %changelog would be the commit date instead 
of author date:


$  git log --pretty=fuller -n 1 fffbc90b
commit fffbc90bcf7a79f918d6ee7f34dfdc43042967c6
Author: Justin Jacobs 
AuthorDate: Tue Oct 12 18:31:17 2021 -0400
Commit: Erik Schilling 
CommitDate: Tue Feb 1 19:42:45 2022 +0100

Update to 1.12 and fix font symlinks

The date when the release happened is good, too.
___
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 2116190] perl-DateTimeX-Easy-0.090 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.fc38   |.fc38
   |perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.fc36   |.fc36
   |perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.el8|.el8
   ||perl-DateTimeX-Easy-0.090-1
   ||.el7



--- Comment #13 from Fedora Update System  ---
FEDORA-EPEL-2022-8ed4f47e9f has been pushed to the Fedora EPEL 7 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=2116190
___
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 2116190] perl-DateTimeX-Easy-0.090 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.fc38   |.fc38
   |perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.fc36   |.fc36
   ||perl-DateTimeX-Easy-0.090-1
   ||.el8



--- Comment #12 from Fedora Update System  ---
FEDORA-EPEL-2022-c51ef03e91 has been pushed to the Fedora EPEL 8 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=2116190
___
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] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-21ae60f43a   
java-latest-openjdk-18.0.2.0.9-1.rolling.el7


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

fedora-repo-zdicts-2208.1-1.el7
tomcat-native-1.2.35-1.el7

Details about builds:



 fedora-repo-zdicts-2208.1-1.el7 (FEDORA-EPEL-2022-1dae5668a8)
 Zstd dictionaries for Fedora repository metadata

Update Information:

Add zdicts for F37 and remove F32 and F33 zdicts

ChangeLog:

* Tue Aug 23 2022 Jonathan Dieter  - 2208.1-1
- Update with F36 dictionaries and drop F32 and F33 dictionaries
* Thu Jul 21 2022 Fedora Release Engineering  - 
2203.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild




 tomcat-native-1.2.35-1.el7 (FEDORA-EPEL-2022-dacb0cdff5)
 Tomcat native library

Update Information:

This update includes a rebase from 1.2.23 up to 1.2.35.  * RHBZ#2119331 Please
build a tomcat-native for version 1.2.35

ChangeLog:

* Wed Aug 24 2022 Hui Wang  - 1.2.35-1
- Update to 1.2.35 (#2119331)


___
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

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

[updates]

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

ansible-collection-community-general-4.8.6-1.el9
cryfs-0.11.2-5.el9
fastfetch-1.6.5-1.el9
goaccess-1.6.2-2.el9
libaiff-6.0-2.el9
openscap-report-0.1.3-0.el9
parallel-20220822-1.el9
pdns-recursor-4.7.2-1.el9
python-flask-basicauth-0.2.0-2.el9
python-retry-0.9.2-2.el9
python-versioneer-0.21-4.el9
ugrep-3.9.2-1.el9
x11vnc-0.9.16-10.el9

Details about builds:



 ansible-collection-community-general-4.8.6-1.el9 (FEDORA-EPEL-2022-27fab14fc2)
 Modules and plugins supported by Ansible community

Update Information:

Update to 4.8.6.

ChangeLog:

* Mon Aug 22 2022 Maxwell G  - 4.8.6-1
- Update to 4.8.6.
* Thu Jul 14 2022 Maxwell G  - 4.8.4-1
- Update to 4.8.4.




 cryfs-0.11.2-5.el9 (FEDORA-EPEL-2022-c1ac7911b8)
 Cryptographic filesystem for the cloud

Update Information:

Initial build on epel9

ChangeLog:

* Wed Jul 20 2022 Fedora Release Engineering  - 
0.11.2-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Wed Jul 20 2022 Mamoru TASAKA  - 0.11.2-4
- Patch for fmt-9
* Sun May 22 2022 Onuralp Sezer  - 0.11.2-3
- Rebuilt for Spdlog #2088633
* Wed May  4 2022 Thomas Rodgers  - 0.11.2-2
- Rebuilt for Boost 1.78
* Sun Mar 27 2022 Onuralp Sezer  - 0.11.2-1
- Version update: 0.11.2
* Sun Feb  6 2022 Onuralp Sezer  - 0.11.1-3
- ExcludeArch: i686
* Sat Feb  5 2022 Neal Gompa  - 0.11.1-2
- Disable building useless internal shared libraries
* Sat Jan 22 2022 Onuralp SEZER  - 0.11.1-1
- initial package




 fastfetch-1.6.5-1.el9 (FEDORA-EPEL-2022-2c8e048650)
 Like neofetch, but much faster because written in c

Update Information:

Update to 1.6.5    add support for package detection    initial package
build

ChangeLog:

* Tue Aug 23 2022 Jonathan Wright  - 1.6.5-1
- Update to 1.6.5
- rhbz#2120472
- Fix typo in first changelog citing "khbz" instead of "rhbz"
* Mon Aug 22 2022 Jonathan Wright  - 1.6.4-3
- Compile with rpm support for listing package counts
* Mon Aug 22 2022 Jonathan Wright  - 1.6.4-2
- Fix spec for EPEL8 builds
* Tue Aug 16 2022 Jonathan Wright  - 1.6.4-1
- Initial package build
- rhbz#2118887




 goaccess-1.6.2-2.el9 (FEDORA-EPEL-2022-9871e4a8c4)
 Real-time web log analyzer and interactive viewer

Update Information:

initial package build for epel9

ChangeLog:

* Tue Aug 23 2022 Jonathan Wright  - 1.6.2-2
- Replace GeoIP with libmaxminddb in f37+ and el9+
* Mon Aug 15 2022 Fabio Alessandro Locati  - 1.6.2-1
- Update to 1.6.2, fixes rhbz#2107794
* Thu Jul 21 2022 Fedora Release Engineering  - 
1.6.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Sun Jul 10 2022 Fabio Alessandro Locati  - 1.6.1-1
- Update to 1.6.1, fixes rhbz#2103284
* Thu Jun  2 2022 Fabio Alessandro Locati  - 1.6-1
- Update to 1.6, fixes rhbz#2080337
* Sun Apr  3 2022 Fabio Alessandro Locati  - 1.5.6-1
- Update to 1.5.6
* Wed Feb  2 2022 Fabio Alessandro Locati  - 1.5.5-1
- Update to 1.5.5
* Thu Jan 20 2022 Fedora Release Engineering  - 
1.5.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Mon Jan  3 2022 Alessio  - 1.5.4-1
- Update to 1.5.4
* Tue Sep 14 2021 Sahana Prasad  - 1.4.6-3
- Rebuilt with OpenSSL 3.0.0
* Thu Jul 22 2021 Fedora Release Engineering  - 
1.4.6-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Sun Mar 14 2021 Eduardo Echeverria  - 1.4.6-1
- Update to 1.4.6
* Sun Feb 14 2021 Eduardo Echeverria  - 1.4.5-1
- Update to 1.4.5 fixes rhbz#1920124
* Tue Jan 26 2021 Fedora Release Engineering  - 
1.4.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
* Thu Jan  7 2021 Filipe Rosset  - 1.4.3-1
- Update to 1.4.3 fixes rhbz#1837101

Re: Users with commit rights in src.fp.o but no more in packager group

[Alasdair G Kergon]

On Wed, Aug 24, 2022 at 09:50:59PM +0200, Fabio Valentini wrote:
> I think some of those *-team / *-sig / *-maint pseudo-group users are
> outdated. Most of them probably pre-date the existence of actual
> groups, so they are probably all ancient. For example, we removed the
> xgl-maint pseudo-group a while ago, because it was actually unused,
> and its associated bugzilla account was disabled.
> I wonder for how many of these groups the same is true, and whether we
> should actually remove them from all packages where that's the case.
 
lvm-team is still in use as a package owner and default bugzilla
assignee.  To do anything of any significance using the account, we were
instructed to open a ticket to ask for the change to be made for us.

It has never been a member of the packager group because it was
decided that accounts that are not individuals cannot sign the
legal agreement that is a pre-requisite to being able to join that
group.

Alasdair
___
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: Adoption of flare package

[Sandro]

On 8/24/22 21:44, Otto Liljalaakso wrote:

Sandro kirjoitti 24.8.2022 klo 14.33:

On 23-08-2022 16:00, Sandro wrote:

I am interested in adopting the orphaned flare package[1]. It doesn't
appear to have any complicated requirements. My local build on a recent
git clone succeeded without effort.


Hello Sandro,

Thank you for taking interest in this.


I became aware of the package being orphaned by the announcement sent a
couple of days ago. While flare is being orphaned, flare-engine is not.

So, I guess my next step would be to contact the current maintainer,
Sandipan Roy aka bytehackr, and discuss with him? Both packages rely on
the same source. I guess he would appreciate a heads up. Maybe he took
flare-engine recently and forgot about flare.


I see that Sandipan has adopted both flare-engine and flare now. It
might still be a good idea to contact them. Both packages still have
missing builds for some releases, and it is always good to have more
than one person taking care of a package.


Yes, after I talked to him he became aware of the dependency between the 
two packages and adopted flare as well.


AFAIK, both packages have been updated to the latest upstream release 
now and built successfully. They should find their way into the 
different repos, soon.



As I'm not in the packagers group, yet, I will have to complete the
sponsoring process first. For that I am looking for a sponsor, too.


Regarding the FTBFS bug [3], it looks like the rebuild failed for the
s390x target. Not sure, this is a desired target. Could probably just be
disabled.


You are misinterpreting the situation. It is true that the only failed
architecture is s390x, but the rest have been cancelled, presumably
because that one failed.

If you check build.log attached to Bugzilla, you will the following error:

  > Error: /builddir/build/BUILD/flare-engine-v1.13/redhat-linux-build is
not a directory

Which looks like a certain horrible problem Fedora has been having with
CMake [1]. It has since then been fixed, or at least worked around, so
just issuing a rebuild should get past that.

However, one part of the cause of that problem is the trailing dot in
the end of '%cmake' [2]. It would be good to remove that. Since you are
interested in starting with package maintenance, that could be a good
first pull request for you.


I'll do that. I'm still in the process of getting acquainted. I tried to 
fork flare and flare-engine earlier, but wasn't able to. Seems like it 
was a temporary issue. Just tried again and it worked.



Building flare-engine also prints out another (non-fatal) error, you
could also correct that in a pull request, just for practice:

error: %changelog not in descending chronological order


I saw that when linting. Wasn't sure how to handle that. The offending 
changelog entry has the right date according to git blame. The releases 
are in the right order. Probably just adjust the date to when that 
release actually happened and silence rpmlint...



Finally, regarding your proposal to disable building on s390x. It is
understandable that it feels useless, because people do not usually play
games on mainframes. However, generally Fedora tries to build everything
on all architectures. So, always first investigate what is the issue,
only resort to ExcludeArch if the problem is really unsolvable for
certain architecture.


Understood. As things stand now, all architectures are building again. 
So, no need to exclude s390x.



Hope this helps, and please ask if anything is unclear.


Thank you. Sandipan asked me to get a certain tool packaged. That will 
be a good exercise as well.


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

[Bug 2119882] perl-Socket-2.036 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Socket-2.036-1.fc38|perl-Socket-2.036-1.fc38
   |perl-Socket-2.036-1.fc37|perl-Socket-2.036-1.fc37
   ||perl-Socket-2.036-1.fc36
Last Closed||2022-08-24 20:31:14



--- Comment #3 from Fedora Update System  ---
FEDORA-2022-abcd05d959 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=2119882
___
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 2116190] perl-DateTimeX-Easy-0.090 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-DateTimeX-Easy-0.090-1 |perl-DateTimeX-Easy-0.090-1
   |.fc38   |.fc38
   ||perl-DateTimeX-Easy-0.090-1
   ||.fc36
 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2022-08-24 20:30:14



--- Comment #11 from Fedora Update System  ---
FEDORA-2022-242fcfacf0 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=2116190
___
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 2116587] perl-Bencode-1.502 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version|perl-Bencode-1.502-1.fc38   |perl-Bencode-1.502-1.fc38
   ||perl-Bencode-1.502-1.fc36
Last Closed||2022-08-24 20:30:46



--- Comment #12 from Fedora Update System  ---
FEDORA-2022-e36979c8f1 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=2116587
___
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 2116479] perl-Alien-pkgconf-0.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version|perl-Alien-pkgconf-0.18-1.f |perl-Alien-pkgconf-0.18-1.f
   |c38 |c38
   ||perl-Alien-pkgconf-0.18-1.f
   ||c36
Last Closed||2022-08-24 20:30:42



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-d45bf79afe 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=2116479
___
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 2118082] perl-DateTime-TimeZone-2.53 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
   Fixed In Version|perl-DateTime-TimeZone-2.53 |perl-DateTime-TimeZone-2.53
   |-1.fc38 |-1.fc38
   |perl-DateTime-TimeZone-2.53 |perl-DateTime-TimeZone-2.53
   |-1.fc37 |-1.fc37
   ||perl-DateTime-TimeZone-2.53
   ||-1.fc36
 Status|ON_QA   |CLOSED
Last Closed||2022-08-24 20:30:06



--- Comment #5 from Fedora Update System  ---
FEDORA-2022-7818db773a 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=2118082
___
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: Users with commit rights in src.fp.o but no more in packager group

[Fabio Valentini]

On Wed, Aug 24, 2022 at 7:31 PM Mattia Verga via devel
 wrote:
>
> Following my comment in
> https://pagure.io/fesco/issue/2856#comment-812870 I wrote a simple
> script to check how many users have commit rights onto some project in
> src.fp.o, but aren't (anymore) members of the `packager` group:
>
> ```
> Found 31 users with commit privileges but not in packager group:
> packaging-team
> stefanok
> mmcgrath
> kernel-maint
> oddshocks
> systemd-maint
> lvm-team
> abrt-team
> i18n-team
> amahdal
> jvlomax
> coremodule
> libvirt-maint
> sonkun
> fonts-sig
> narasim
> perl-sig
> dcr226
> gecko-maint
> ozamosi
> sheltren
> anaconda-maint
> java-sig
> duriantang
> dracut-maint
> ipa-maint
> kmod-maint
> mariobl
> mck182
> design-sw
> cdeccio
> ```
>
> With the exclusion of *-team, *-sig and *-maint, I think packaging
> rights should be removed from those users.
> Also, as per my comment linked above, I think there should be some check
> to prevent users removed from packager group to maintain commit rights.
> No idea where/how to implement that.

I think some of those *-team / *-sig / *-maint pseudo-group users are
outdated. Most of them probably pre-date the existence of actual
groups, so they are probably all ancient. For example, we removed the
xgl-maint pseudo-group a while ago, because it was actually unused,
and its associated bugzilla account was disabled.
I wonder for how many of these groups the same is true, and whether we
should actually remove them from all packages where that's the case.

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: Adoption of flare package

[Otto Liljalaakso]

Sandro kirjoitti 24.8.2022 klo 14.33:

On 23-08-2022 16:00, Sandro wrote:

I am interested in adopting the orphaned flare package[1]. It doesn't
appear to have any complicated requirements. My local build on a recent
git clone succeeded without effort.


Hello Sandro,

Thank you for taking interest in this.

I became aware of the package being orphaned by the announcement sent a 
couple of days ago. While flare is being orphaned, flare-engine is not.


So, I guess my next step would be to contact the current maintainer, 
Sandipan Roy aka bytehackr, and discuss with him? Both packages rely on 
the same source. I guess he would appreciate a heads up. Maybe he took 
flare-engine recently and forgot about flare.


I see that Sandipan has adopted both flare-engine and flare now. It 
might still be a good idea to contact them. Both packages still have 
missing builds for some releases, and it is always good to have more 
than one person taking care of a package.



As I'm not in the packagers group, yet, I will have to complete the
sponsoring process first. For that I am looking for a sponsor, too.


Regarding the FTBFS bug [3], it looks like the rebuild failed for the 
s390x target. Not sure, this is a desired target. Could probably just be 
disabled.


You are misinterpreting the situation. It is true that the only failed 
architecture is s390x, but the rest have been cancelled, presumably 
because that one failed.


If you check build.log attached to Bugzilla, you will the following error:

> Error: /builddir/build/BUILD/flare-engine-v1.13/redhat-linux-build is 
not a directory


Which looks like a certain horrible problem Fedora has been having with 
CMake [1]. It has since then been fixed, or at least worked around, so 
just issuing a rebuild should get past that.


However, one part of the cause of that problem is the trailing dot in 
the end of '%cmake' [2]. It would be good to remove that. Since you are 
interested in starting with package maintenance, that could be a good 
first pull request for you.


Building flare-engine also prints out another (non-fatal) error, you 
could also correct that in a pull request, just for practice:


error: %changelog not in descending chronological order

Finally, regarding your proposal to disable building on s390x. It is 
understandable that it feels useless, because people do not usually play 
games on mainframes. However, generally Fedora tries to build everything 
on all architectures. So, always first investigate what is the issue, 
only resort to ExcludeArch if the problem is really unsolvable for 
certain architecture.


Hope this helps, and please ask if anything is unclear.

[1]: https://bugzilla.redhat.com/show_bug.cgi?id=2059201
[2]: 
https://src.fedoraproject.org/rpms/flare-engine/blob/rawhide/f/flare-engine.spec#_46

___
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: Ruby FTBFS due to "SHA-1 jump scare"

[Adam Williamson]

On Wed, 2022-08-24 at 16:58 +0200, Alexander Sosedkin wrote:
> 
> Reverted in crypto-policies-20220824-2.git2187e9c.fc38,
> sorry for the premature jump scare.

openQA caught an interesting consequence of the change while it was
live: it makes PackageKit start crashing. The journal shows these
errors:

Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: failed to parse public 
key for /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-13-secondary
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the 
top of a previous GError or uninitialized memory.
 This indicates a bug 
in someone's code. You must ensure an error is NULL before it's set.
 The overwriting error 
message was: failed to parse public key for 
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-14-secondary
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null)
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the 
top of a previous GError or uninitialized memory.
 This indicates a bug 
in someone's code. You must ensure an error is NULL before it's set.
 The overwriting error 
message was: failed to parse public key for 
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-15-secondary
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null)
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the 
top of a previous GError or uninitialized memory.
 This indicates a bug 
in someone's code. You must ensure an error is NULL before it's set.
 The overwriting error 
message was: failed to parse public key for 
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-16-secondary
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null)
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the 
top of a previous GError or uninitialized memory.
 This indicates a bug 
in someone's code. You must ensure an error is NULL before it's set.
 The overwriting error 
message was: failed to parse public key for 
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-17-secondary
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null)
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the 
top of a previous GError or uninitialized memory.
 This indicates a bug 
in someone's code. You must ensure an error is NULL before it's set.
 The overwriting error 
message was: failed to parse public key for 
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-18-secondary
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null)
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the 
top of a previous GError or uninitialized memory.
 This indicates a bug 
in someone's code. You must ensure an error is NULL before it's set.
 The overwriting error 
message was: failed to parse public key for 
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-19-secondary
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null)
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the 
top of a previous GError or uninitialized memory.
 This indicates a bug 
in someone's code. You must ensure an error is NULL before it's set.
 The overwriting error 
message was: failed to parse public key for 
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-20-secondary
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null)
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the 
top of a previous GError or uninitialized memory.
 This indicates a bug 
in someone's code. You must ensure an error is NULL before it's set.
 The overwriting error 
message was: failed to parse public key for 
/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-21-secondary
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: (null)
Aug 24 03:50:39 localhost.localdomain packagekitd[1397]: GError set over the 
top of a previous GError or uninitialized memory.
 This indicates a bug 
in someone's code. You must ensure an error is NULL before it's set.
 The overwriting error 
message was: failed to parse public key for 
/etc/pki/rpm-gpg/RPM-GPG-KEY-

Fedora CoreOS Meeting Minutes 2022-08-24

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-08-24/fedora_coreos_meeting.2022-08-24-16.32.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-08-24/fedora_coreos_meeting.2022-08-24-16.32.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-08-24/fedora_coreos_meeting.2022-08-24-16.32.log.html


#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:32:15 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2022-08-24/fedora_coreos_meeting.2022-08-24-16.32.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:32:19)

* Action items from last meeting  (dustymabe, 16:36:36)
  * no action items from last meeting!  (dustymabe, 16:36:49)

* tracker: Fedora 37 changes considerations   (dustymabe, 16:37:00)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1222
(dustymabe, 16:37:16)
  * the hostname change got into f38/f37:

https://github.com/coreos/fedora-coreos-tracker/issues/902#issuecomment-1225839825
(dustymabe, 16:39:12)
  * the macaddresspolicy change fell out (thomas got busy and went on
vacation) but we'll get it into F38.
https://fedoraproject.org/wiki/Changes/MAC_Address_Policy_none
(dustymabe, 16:39:19)

* Document /boot requirements and constrains when installing/upgrading
  kernels  (dustymabe, 16:45:59)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1247
(dustymabe, 16:46:03)
  * LINK: https://github.com/coreos/fedora-coreos-docs/issues/410
(travier, 17:03:39)
  * LINK:

https://github.com/coreos/fedora-coreos-tracker/issues/1196#issuecomment-1132428498
(travier, 17:03:52)
  * LINK:
https://github.com/ostreedev/ostree/issues/2670#issuecomment-1179341883
(jlebon, 17:14:45)
  * AGREED: we discussed the different options for solving this general
problem here today. Right now we don't see a clear path forward for
changing the /boot/ partition size without risking data loss while
re-provisioning systems. We're going to investigate the other
options and also brainstorm on how we can increase the /boot
partition in the future. For now we'll try to get at least the
(dustymabe, 17:32:38)

* NetworkManager: consider defaulting to EUI-64 for IPv6 SLAAC (at least
  on OpenStack)  (dustymabe, 17:33:49)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/907
(dustymabe, 17:33:58)
  * AGREED: we will set ipv6.addr-gen-mode=eui64 as the default on our
OpenStack platform since the platform expects this to be the case.
We will attempt to leave currently deployed systems alone so that we
don't change an existing system's IP address.  (dustymabe, 17:41:17)

* Pinning coreos-assembler in FCOS releases  (dustymabe, 17:41:27)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1068
(dustymabe, 17:41:31)

* open floor  (dustymabe, 17:45:24)

Meeting ended at 17:48:17 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (136)
* bgilbert (45)
* jlebon (41)
* travier (31)
* zodbot (19)
* jmarrero (5)
* ravanelli (3)
* jbrooks (1)
* lorbus (1)
* aaradhak (1)




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 2120413] perl-Locale-Maketext-1.32 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-a7f4abd7ee has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-a7f4abd7ee`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-a7f4abd7ee

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120413
___
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 2120625] perl-Config-Perl-V-0.34 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2022-9d9488d6bf has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2022-9d9488d6bf`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-9d9488d6bf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


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

Users with commit rights in src.fp.o but no more in packager group

[Mattia Verga via devel]

Following my comment in
https://pagure.io/fesco/issue/2856#comment-812870 I wrote a simple
script to check how many users have commit rights onto some project in
src.fp.o, but aren't (anymore) members of the `packager` group:

```
Found 31 users with commit privileges but not in packager group:
packaging-team
stefanok
mmcgrath
kernel-maint
oddshocks
systemd-maint
lvm-team
abrt-team
i18n-team
amahdal
jvlomax
coremodule
libvirt-maint
sonkun
fonts-sig
narasim
perl-sig
dcr226
gecko-maint
ozamosi
sheltren
anaconda-maint
java-sig
duriantang
dracut-maint
ipa-maint
kmod-maint
mariobl
mck182
design-sw
cdeccio
```

With the exclusion of *-team, *-sig and *-maint, I think packaging
rights should be removed from those users.
Also, as per my comment linked above, I think there should be some check
to prevent users removed from packager group to maintain commit rights.
No idea where/how to implement that.

Mattia

___
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: [Fedora-legal-list] Re: Consider changing the license change announcement policy

[Richard Fontana]

On Wed, Aug 24, 2022 at 1:00 PM Jilayne Lovejoy  wrote:
>
>
>
> On 8/24/22 8:56 AM, Richard Fontana wrote:
> > Cross-posting this to the devel list.
> >
> > On Tue, Aug 23, 2022 at 11:41 PM Maxwell G  wrote:
> >> Hi Legal folks,
> >>
> >> Can you please consider removing the following rule?
> >>
> >>> Fedora package maintainers are expected to announce upstream license
> >>> changes that they become aware of on the Fedora devel list.
> >> -- 
> >> https://docs.fedoraproject.org/en-US/legal/license-review-process/#_what_if_the_license_for_a_fedora_package_changes
> >>
> >> This creates unnecessary friction for packagers that simply wish to have
> >> correct License fields. I'm also not sure what purposes it serves.
> >> Richard explicitly said that Fedora does not concern itself with
> >> cross-package license compatibility.
> > That's typically been the case, yes (and for other Linux distributions too).
> >
> >> And even if it did, a "GPLv3+" to
> >> "GPL-3.0-or-later AND MIT" license change shouldn't cause any new
> >> license compatibility issues.
> > I am inclined to agree with Maxwell here. I'm guessing this
> > expectation must have originated pretty early on and mainly out of
> > concerns about identifying cross-package license incompatibility
> > situations (I can't really see what other practical purpose the
> > announcement would serve). While Fedora package maintainers need to be
> > on alert to any upstream license changes, I think this rule is sort of
> > out of step with how such upstream license changes may often occur and
> > is also out of step with how we are now focusing somewhat more closely
> > on the details of upstream source code licensing.
> >
> > However, maybe there is some benefit to this announcement rule I am
> > not seeing. Has an announcement of an upstream license change on the
> > devel list (assuming the license change is to some other license known
> > to be allowed in Fedora) ever led to some action on the part of
> > maintainers of other packages?
> I think this is sort of why we simply kept this policy as-is for the
> time being - in case there was some benefit we hadn't thought of. I
> recall questioning this was to devel instead of legal mailing list but I
> think we presumed that was due to the larger audience on devel.

> In any case, the one benefit I see at the moment is during this
> transition to SPDX, it raises awareness and visibility in case people
> need some guidance and may not realize it.  Over the long haul, I could
> see dropping it though.

If the main concern is guidance around the transition to SPDX, then
the better audience is the legal list, not the devel list. But I think
it might be better to encourage people with questions relating to the
transition to SPDX to submit issues to
https://gitlab.com/fedora/legal/fedora-license-data.

One concern I have about the traditional rule is that it seems to
encourage a view that 'small upstream license changes don't really
matter' (because in practice no one generally interpreted the rule to
apply to such changes, I'm pretty sure) -- which might very well not
be the case. By 'small' I mean 'only covers a small portion of the
upstream project source code' as opposed to some major global project
license change.

To take a fairly random recent example, from a Fedora policy
standpoint the license change noted in this ticket
https://bugzilla.redhat.com/show_bug.cgi?id=2116859 is pretty
significant, but compliance with the 'announce license changes' rule
would probably never have caught it. As it happens, that license
change was brought up on the legal list by someone other than the
maintainer of the relevant package(s). Instead the kinds of license
changes that I've seen announced on the devel list over the years seem
fairly insignificant, like GPLv2+ to GPLv3+.

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: [Fedora-legal-list] Re: Consider changing the license change announcement policy

[Jilayne Lovejoy]

On 8/24/22 8:56 AM, Richard Fontana wrote:

Cross-posting this to the devel list.

On Tue, Aug 23, 2022 at 11:41 PM Maxwell G  wrote:

Hi Legal folks,

Can you please consider removing the following rule?


Fedora package maintainers are expected to announce upstream license
changes that they become aware of on the Fedora devel list.

-- 
https://docs.fedoraproject.org/en-US/legal/license-review-process/#_what_if_the_license_for_a_fedora_package_changes

This creates unnecessary friction for packagers that simply wish to have
correct License fields. I'm also not sure what purposes it serves.
Richard explicitly said that Fedora does not concern itself with
cross-package license compatibility.

That's typically been the case, yes (and for other Linux distributions too).


And even if it did, a "GPLv3+" to
"GPL-3.0-or-later AND MIT" license change shouldn't cause any new
license compatibility issues.

I am inclined to agree with Maxwell here. I'm guessing this
expectation must have originated pretty early on and mainly out of
concerns about identifying cross-package license incompatibility
situations (I can't really see what other practical purpose the
announcement would serve). While Fedora package maintainers need to be
on alert to any upstream license changes, I think this rule is sort of
out of step with how such upstream license changes may often occur and
is also out of step with how we are now focusing somewhat more closely
on the details of upstream source code licensing.

However, maybe there is some benefit to this announcement rule I am
not seeing. Has an announcement of an upstream license change on the
devel list (assuming the license change is to some other license known
to be allowed in Fedora) ever led to some action on the part of
maintainers of other packages?
I think this is sort of why we simply kept this policy as-is for the 
time being - in case there was some benefit we hadn't thought of. I 
recall questioning this was to devel instead of legal mailing list but I 
think we presumed that was due to the larger audience on devel.


In any case, the one benefit I see at the moment is during this 
transition to SPDX, it raises awareness and visibility in case people 
need some guidance and may not realize it.  Over the long haul, I could 
see dropping it though.


Jilayne



Richard
___
legal mailing list -- le...@lists.fedoraproject.org
To unsubscribe send an email to legal-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/le...@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: F37 side tag after branching point

[Kevin Fenzi]

Just to chime in from a releng perspective here... 

IMHO you should do builds for f38 now also (either by making a side tag
and bootstrapping them just like was done for f37, or tagging f37 builds
you need into the f38 sidetag). 

While it's technically possible to push the f37 builds into rawhide
also, it would take releng manually tagging them in, bypassing bodhi,
gating and CI completely. It's much better to build again for
f38/rawhide and let those builds get checked by gating and CI, etc. 

If you run into any problems, let me know...

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Re: duplicates

[Madeline Reilly-Watson]

Thanks so much Troy, Yes I inherited this environment. I will look for you 
clues.

Have a great day!!


From: Troy Dawson 
Sent: Wednesday, August 24, 2022 11:09 AM
To: EPEL Development List 
Subject: [EPEL-devel] Re: duplicates

Hi Lynn,
I think you need to contact whoever setup your spacewalk / satellite system.  
They are the owners of epel7-centos7-x86_64, not the EPEL community.
epel7-centos7-x86_64 is a custom repository, that I am betting is on your 
spacewalk system.

There are three clues for this.
1st - epel7 is for all RHEL compatible distributions, not just centos7
2nd - Although there are security updates in epel, we never generate CEEA.  
CentOS 7 on the other hand does generate CEEA information.
3rd - The names are just wrong.  An original epel repo would be "epel" or 
"Extra Packages for Enterprise Linux 7".So someone, somewhere, has edited 
the repository info.

I hope you are able to find a solution.
Troy


On Mon, Aug 22, 2022 at 12:48 PM Madeline Reilly-Watson 
mailto:mreilly-wat...@lancerinsurance.com>> 
wrote:
Hi,

We are getting this on many servers and so I was asked to report. Any ideas

Thank you


Update notice CEEA-2019:2270 (from epel7-centos7-x86_64) is broken, or a bad 
duplicate, skipping.



You should report this problem to the owner of the epel7-centos7-x86_64 
repository.



yum updateinfo –verbose

Loading "rhnplugin" plugin

Loading "fastestmirror" plugin

Loading "fusioninventory-agent" plugin Loading "tmprepo" plugin

Config

time: 0.046

*Note* Spacewalk repositories are not listed below. You must run this command 
as root to access Spacewalk repositories.

Yum version: 3.4.3

rpmdb time: 0.000

Setting up Package Sacks

updateinfo time: 0.000

Building updates object

Setting up Package Sacks

Setting up Package Sacks

up:Obs Init time: 0.000

up:simple updates time: 0.000

up:obs time: 0.000

up:condense time: 0.000

updates time: 0.006

updateinfo summary done

sudo yum updateinfo –verbose

[sudo] password for

Loading "rhnplugin" plugin

Loading "fastestmirror" plugin

Loading "fusioninventory-agent" plugin Loading "tmprepo" plugin

 Config

time: 0.045 This system is receiving updates from RHN Classic or Red

 Hat Satellite.

Looking for repo options for [main]

Looking for repo options for [centos7-x86_64] Repo 'centos7-x86_64'

setting option 'enabled' = '1'

Repo 'centos7-x86_64' setting option 'gpgcheck' = '1'

Repo 'centos7-x86_64' setting option 'timeout' = '120'

Looking for repo options for [main]

Looking for repo options for [centos7-x86_64-updates] Repo

centos7-x86_64-updates' setting option 'enabled' = '1'

Repo 'centos7-x86_64-updates' setting option 'gpgcheck' = '1'

Repo 'centos7-x86_64-updates' setting option 'timeout' = '120'

Looking for repo options for [main]

Looking for repo options for [centos7-x86_64-extras] Repo

 'centos7-x86_64-extras' setting option 'enabled' = '1'

Repo 'centos7-x86_64-extras' setting option 'gpgcheck' = '1'

Repo 'centos7-x86_64-extras' setting option 'timeout' = '120'

Looking for repo options for [main]

Looking for repo options for [epel7-centos7-x86_64] Repo

'epel7-centos7-x86_64' setting option 'enabled' = '1'

Repo 'epel7-centos7-x86_64' setting option 'gpgcheck' = '1'

Repo 'epel7-centos7-x86_64' setting option 'timeout' = '120'

Looking for repo options for [main]

Looking for repo options for [spacewalk29-client-centos7-x86_64]

Repo 'spacewalk29-client-centos7-x86_64' setting option 'enabled' = '1'

Repo 'spacewalk29-client-centos7-x86_64' setting option 'gpgcheck' = '1'

Repo 'spacewalk29-client-centos7-x86_64' setting option 'timeout' = '120'

Looking for repo options for [main]

Looking for repo options for [trasher-fusioninventory-agent] Repo

'trasher-fusioninventory-agent' setting option 'enabled' = '1'

Repo 'trasher-fusioninventory-agent' setting option 'gpgcheck' = '1'

Repo 'trasher-fusioninventory-agent' setting option 'timeout' = '120'

Looking for repo options for [main]

Looking for repo options for [openldap-tb] Repo 'openldap-tb'

setting option 'enabled' = '1'

Repo 'openldap-tb' setting option 'gpgcheck' = '1'

Repo 'openldap-tb' setting option 'timeout' = '120'

Yum version: 3.4.3

rpmdb time: 0.000

Setting up Package Sacks

Loading mirror speeds from cached hostfile pkgsack time: 0.054

Duplicate of CEEA-2019:2270 differs in some fields:

<<< epel7-centos7-x86_64:issued

'2019-08-30 03:47:24'

===

'2019-01-30 00:08:00'

>>> centos7-x86_64:issued

Update notice CEEA-2019:2270 (from epel7-centos7-x86_64) is broken, or a bad 
duplicate, skipping.

You should report this problem to the owner of the epel7-centos7-x86_64 
repository.

To help pinpoint the issue, please attach the output of "yum updateinfo 
--verbose" to the report.

updateinfo time: 1.551

Building updates object

up:Obs Init time: 0.525

up:simple updates time: 0.011

up:obs time: 0.006

up:condense time: 0.000

updates time: 1.378

Updates Information Summary: updates

8 Security notice(s)

3 Bugfix 

[EPEL-devel] Re: duplicates

[Troy Dawson]

Hi Lynn,
I think you need to contact whoever setup your spacewalk / satellite
system.  They are the owners of epel7-centos7-x86_64, not the EPEL
community.
epel7-centos7-x86_64 is a custom repository, that I am betting is on your
spacewalk system.

There are three clues for this.
1st - epel7 is for all RHEL compatible distributions, not just centos7
2nd - Although there are security updates in epel, we never generate CEEA.
CentOS 7 on the other hand does generate CEEA information.
3rd - The names are just wrong.  An original epel repo would be "epel" or
"Extra Packages for Enterprise Linux 7".So someone, somewhere, has
edited the repository info.

I hope you are able to find a solution.
Troy


On Mon, Aug 22, 2022 at 12:48 PM Madeline Reilly-Watson <
mreilly-wat...@lancerinsurance.com> wrote:

> Hi,
>
>
>
> We are getting this on many servers and so I was asked to report. Any ideas
>
>
>
> Thank you
>
>
>
> Update notice CEEA-2019:2270 (from epel7-centos7-x86_64) is broken, or a
> bad duplicate, skipping.
>
>
>
> You should report this problem to the owner of the epel7-centos7-x86_64
> repository.
>
>
>
> yum updateinfo –verbose
>
> Loading "rhnplugin" plugin
>
> Loading "fastestmirror" plugin
>
> Loading "fusioninventory-agent" plugin Loading "tmprepo" plugin
>
> Config
>
> time: 0.046
>
> *Note* Spacewalk repositories are not listed below. You must run this
> command as root to access Spacewalk repositories.
>
> Yum version: 3.4.3
>
> rpmdb time: 0.000
>
> Setting up Package Sacks
>
> updateinfo time: 0.000
>
> Building updates object
>
> Setting up Package Sacks
>
> Setting up Package Sacks
>
> up:Obs Init time: 0.000
>
> up:simple updates time: 0.000
>
> up:obs time: 0.000
>
> up:condense time: 0.000
>
> updates time: 0.006
>
> updateinfo summary done
>
> sudo yum updateinfo –verbose
>
> [sudo] password for
>
> Loading "rhnplugin" plugin
>
> Loading "fastestmirror" plugin
>
> Loading "fusioninventory-agent" plugin Loading "tmprepo" plugin
>
>  Config
>
> time: 0.045 This system is receiving updates from RHN Classic or Red
>
>  Hat Satellite.
>
> Looking for repo options for [main]
>
> Looking for repo options for [centos7-x86_64] Repo 'centos7-x86_64'
>
> setting option 'enabled' = '1'
>
> Repo 'centos7-x86_64' setting option 'gpgcheck' = '1'
>
> Repo 'centos7-x86_64' setting option 'timeout' = '120'
>
> Looking for repo options for [main]
>
> Looking for repo options for [centos7-x86_64-updates] Repo
>
> centos7-x86_64-updates' setting option 'enabled' = '1'
>
> Repo 'centos7-x86_64-updates' setting option 'gpgcheck' = '1'
>
> Repo 'centos7-x86_64-updates' setting option 'timeout' = '120'
>
> Looking for repo options for [main]
>
> Looking for repo options for [centos7-x86_64-extras] Repo
>
>  'centos7-x86_64-extras' setting option 'enabled' = '1'
>
> Repo 'centos7-x86_64-extras' setting option 'gpgcheck' = '1'
>
> Repo 'centos7-x86_64-extras' setting option 'timeout' = '120'
>
> Looking for repo options for [main]
>
> Looking for repo options for [epel7-centos7-x86_64] Repo
>
> 'epel7-centos7-x86_64' setting option 'enabled' = '1'
>
> Repo 'epel7-centos7-x86_64' setting option 'gpgcheck' = '1'
>
> Repo 'epel7-centos7-x86_64' setting option 'timeout' = '120'
>
> Looking for repo options for [main]
>
> Looking for repo options for [spacewalk29-client-centos7-x86_64]
>
> Repo 'spacewalk29-client-centos7-x86_64' setting option 'enabled' = '1'
>
> Repo 'spacewalk29-client-centos7-x86_64' setting option 'gpgcheck' = '1'
>
> Repo 'spacewalk29-client-centos7-x86_64' setting option 'timeout' = '120'
>
> Looking for repo options for [main]
>
> Looking for repo options for [trasher-fusioninventory-agent] Repo
>
> 'trasher-fusioninventory-agent' setting option 'enabled' = '1'
>
> Repo 'trasher-fusioninventory-agent' setting option 'gpgcheck' = '1'
>
> Repo 'trasher-fusioninventory-agent' setting option 'timeout' = '120'
>
> Looking for repo options for [main]
>
> Looking for repo options for [openldap-tb] Repo 'openldap-tb'
>
> setting option 'enabled' = '1'
>
> Repo 'openldap-tb' setting option 'gpgcheck' = '1'
>
> Repo 'openldap-tb' setting option 'timeout' = '120'
>
> Yum version: 3.4.3
>
> rpmdb time: 0.000
>
> Setting up Package Sacks
>
> Loading mirror speeds from cached hostfile pkgsack time: 0.054
>
> Duplicate of CEEA-2019:2270 differs in some fields:
>
> <<< epel7-centos7-x86_64:issued
>
> '2019-08-30 03:47:24'
>
> ===
>
> '2019-01-30 00:08:00'
>
> >>> centos7-x86_64:issued
>
> Update notice CEEA-2019:2270 (from epel7-centos7-x86_64) is broken, or a
> bad duplicate, skipping.
>
> You should report this problem to the owner of the epel7-centos7-x86_64
> repository.
>
> To help pinpoint the issue, please attach the output of "yum updateinfo
> --verbose" to the report.
>
> updateinfo time: 1.551
>
> Building updates object
>
> up:Obs Init time: 0.525
>
> up:simple updates time: 0.011
>
> up:obs time: 0.006
>
> up:condense time: 0.000
>
> updates time: 1.378
>
> Updates Information 

Re: Ruby FTBFS due to "SHA-1 jump scare"

[Vít Ondruch]

Dne 24. 08. 22 v 16:58 Alexander Sosedkin napsal(a):

On Wed, Aug 24, 2022 at 4:33 PM Alexander Sosedkin  wrote:

On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini  wrote:

On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin  wrote:

On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch  wrote:

Alexander,

Would you mind to comment on your intentions with:

https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide

which just landed in Fedora and broke Ruby test suite (even more then it
was broken before):

https://koschei.fedoraproject.org/package/ruby

Although I know something like this was discussed and is already enabled
in c9s,

Yes, it was: [2], [3]


I am not aware that the associated change [1] would be approved
nor that you would send a warning that this is going to happen.

Wait, right. It was just the Forewarning1 [4] that was approved,
not the Forewarning2 one.


Am I missing something?

My intention was to break it right at the branch-off.
What do I do now? Just keep it as it is?
Revert, somehow initiate the approval early and unrevert once I have one?

I don't think keeping rawhide/f38 intentionally broken, even if you're
going to revert the brokenness in f38 after it branches off, is ever a
good idea.
Please revert the change and wait for the devel list and FESCo
discussion of the topic before implementing it again.

Ack, will do promptly. My bad.

Reverted in crypto-policies-20220824-2.git2187e9c.fc38,



Thx



sorry for the premature jump scare.



Also thx for reminding us that we should work with upstream to have it 
properly resolved, because it would already help with c9s ;)



Vít




OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Ruby FTBFS due to "SHA-1 jump scare"

[Alexander Sosedkin]

On Wed, Aug 24, 2022 at 4:33 PM Alexander Sosedkin  wrote:
>
> On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini  wrote:
> >
> > On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin  
> > wrote:
> > >
> > > On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch  wrote:
> > > >
> > > > Alexander,
> > > >
> > > > Would you mind to comment on your intentions with:
> > > >
> > > > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide
> > > >
> > > > which just landed in Fedora and broke Ruby test suite (even more then it
> > > > was broken before):
> > > >
> > > > https://koschei.fedoraproject.org/package/ruby
> > > >
> > > > Although I know something like this was discussed and is already enabled
> > > > in c9s,
> > >
> > > Yes, it was: [2], [3]
> > >
> > > > I am not aware that the associated change [1] would be approved
> > > > nor that you would send a warning that this is going to happen.
> > >
> > > Wait, right. It was just the Forewarning1 [4] that was approved,
> > > not the Forewarning2 one.
> > >
> > > > Am I missing something?
> > >
> > > My intention was to break it right at the branch-off.
> > > What do I do now? Just keep it as it is?
> > > Revert, somehow initiate the approval early and unrevert once I have one?
> >
> > I don't think keeping rawhide/f38 intentionally broken, even if you're
> > going to revert the brokenness in f38 after it branches off, is ever a
> > good idea.
> > Please revert the change and wait for the devel list and FESCo
> > discussion of the topic before implementing it again.
>
> Ack, will do promptly. My bad.

Reverted in crypto-policies-20220824-2.git2187e9c.fc38,
sorry for the premature jump scare.
___
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: [Fedora-legal-list] Consider changing the license change announcement policy

[Richard Fontana]

Cross-posting this to the devel list.

On Tue, Aug 23, 2022 at 11:41 PM Maxwell G  wrote:
>
> Hi Legal folks,
>
> Can you please consider removing the following rule?
>
> > Fedora package maintainers are expected to announce upstream license
> > changes that they become aware of on the Fedora devel list.
>
> -- 
> https://docs.fedoraproject.org/en-US/legal/license-review-process/#_what_if_the_license_for_a_fedora_package_changes
>
> This creates unnecessary friction for packagers that simply wish to have
> correct License fields. I'm also not sure what purposes it serves.
> Richard explicitly said that Fedora does not concern itself with
> cross-package license compatibility.

That's typically been the case, yes (and for other Linux distributions too).

> And even if it did, a "GPLv3+" to
> "GPL-3.0-or-later AND MIT" license change shouldn't cause any new
> license compatibility issues.

I am inclined to agree with Maxwell here. I'm guessing this
expectation must have originated pretty early on and mainly out of
concerns about identifying cross-package license incompatibility
situations (I can't really see what other practical purpose the
announcement would serve). While Fedora package maintainers need to be
on alert to any upstream license changes, I think this rule is sort of
out of step with how such upstream license changes may often occur and
is also out of step with how we are now focusing somewhat more closely
on the details of upstream source code licensing.

However, maybe there is some benefit to this announcement rule I am
not seeing. Has an announcement of an upstream license change on the
devel list (assuming the license change is to some other license known
to be allowed in Fedora) ever led to some action on the part of
maintainers of other packages?

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: HEADS UP: ffmpeg 5.1 update for F37+ incoming

[Petr Pisar]

V Wed, Aug 24, 2022 at 09:55:39AM -0400, Neal Gompa napsal(a):
> Hey all,
> 
> I'm updating ffmpeg to 5.1 to synchronize with third-party
> repositories that use this version for F37+. Because there were some
> failed builds from the F37 mass build due to bootstrap cycles, I'm
> using this as an opportunity to clean that up too. There is also some
> ELN fallout to deal with, too.
> 
> I will do this later today or tomorrow, depending on when I can make
> the time for it.
> 
> Based on a repoquery, these are the reverse dependencies:
> 
> * attract-mode
> * blender
> * chromaprint
> * indi-3rdparty-drivers
> * loudgain
> * notcurses
> * siril
>
ffmpeg has multiple subpackages. E.g. libavcodec-free and repoquery lists for
it:

attract-mode-2.6.2-3.fc37.src.rpm
blender-3.2.2-1.fc37.src.rpm
chromaprint-1.5.1-4.fc37.src.rpm
indi-3rdparty-drivers-1.9.7-1.fc37.src.rpm
loudgain-0.6.8-10.fc37.src.rpm
neatvnc-0.5.1-2.fc37.src.rpm
notcurses-3.0.8-3.fc37.src.rpm
siril-1.0.3-3.fc38.src.rpm
unpaper-7.0.0-2.fc37.src.rpm

There is neatvnc and unpaper in addition to your list.

Though I don't know which ffmpeg libraries are changing ABI. Maybe not all
of the packages need a rebuild.

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

Re: GNOME's Icon Development Kit icons potentially causing implicit conflicts

[Lyes Saadi]

I have tried to create a package for that, including rpm-macros to 
easily remove conflicting installed icons.


Here it is: 
https://lyessaadi.fedorapeople.org/icon-development-kit-2022.08.18-1.fc38.src.rpm


Should I submit that for review and change conflicting packages? Or 
should we instead instruct packagers to fix their apps?


Regards,
Lyes Saadi

Le 24/08/2022 à 10:40, Lyes Saadi a écrit :
Le 24/08/2022 à 09:47, Vít Ondruch a écrit :> Shouldn't we have shared 
"Icon Library" package, which would solve the

conflicts?



Yes, this is what I'm also proposing, and what I think is probably the 
most painless solution. Additionally, since packages like 
gnome-control-center install icons this way, it would make it harder to 
miss the potential conflicts.


Although, I think that the Icon Library app doesn't put apps in 
categories nor does it install them system-wide. I think it would be 
easier to package Icon Development Kit itself.


Regards,
Lyes Saadi
___
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: Ruby FTBFS due to "SHA-1 jump scare"

[Alexander Sosedkin]

On Wed, Aug 24, 2022 at 4:32 PM Fabio Valentini  wrote:
>
> On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin  
> wrote:
> >
> > On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch  wrote:
> > >
> > > Alexander,
> > >
> > > Would you mind to comment on your intentions with:
> > >
> > > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide
> > >
> > > which just landed in Fedora and broke Ruby test suite (even more then it
> > > was broken before):
> > >
> > > https://koschei.fedoraproject.org/package/ruby
> > >
> > > Although I know something like this was discussed and is already enabled
> > > in c9s,
> >
> > Yes, it was: [2], [3]
> >
> > > I am not aware that the associated change [1] would be approved
> > > nor that you would send a warning that this is going to happen.
> >
> > Wait, right. It was just the Forewarning1 [4] that was approved,
> > not the Forewarning2 one.
> >
> > > Am I missing something?
> >
> > My intention was to break it right at the branch-off.
> > What do I do now? Just keep it as it is?
> > Revert, somehow initiate the approval early and unrevert once I have one?
>
> I don't think keeping rawhide/f38 intentionally broken, even if you're
> going to revert the brokenness in f38 after it branches off, is ever a
> good idea.
> Please revert the change and wait for the devel list and FESCo
> discussion of the topic before implementing it again.

Ack, will do promptly. My bad.
___
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: Ruby FTBFS due to "SHA-1 jump scare"

[Fabio Valentini]

On Wed, Aug 24, 2022 at 4:28 PM Alexander Sosedkin  wrote:
>
> On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch  wrote:
> >
> > Alexander,
> >
> > Would you mind to comment on your intentions with:
> >
> > https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide
> >
> > which just landed in Fedora and broke Ruby test suite (even more then it
> > was broken before):
> >
> > https://koschei.fedoraproject.org/package/ruby
> >
> > Although I know something like this was discussed and is already enabled
> > in c9s,
>
> Yes, it was: [2], [3]
>
> > I am not aware that the associated change [1] would be approved
> > nor that you would send a warning that this is going to happen.
>
> Wait, right. It was just the Forewarning1 [4] that was approved,
> not the Forewarning2 one.
>
> > Am I missing something?
>
> My intention was to break it right at the branch-off.
> What do I do now? Just keep it as it is?
> Revert, somehow initiate the approval early and unrevert once I have one?

I don't think keeping rawhide/f38 intentionally broken, even if you're
going to revert the brokenness in f38 after it branches off, is ever a
good idea.
Please revert the change and wait for the devel list and FESCo
discussion of the topic before implementing it again.

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: Ruby FTBFS due to "SHA-1 jump scare"

[Alexander Sosedkin]

On Wed, Aug 24, 2022 at 4:18 PM Vít Ondruch  wrote:
>
> Alexander,
>
> Would you mind to comment on your intentions with:
>
> https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide
>
> which just landed in Fedora and broke Ruby test suite (even more then it
> was broken before):
>
> https://koschei.fedoraproject.org/package/ruby
>
> Although I know something like this was discussed and is already enabled
> in c9s,

Yes, it was: [2], [3]

> I am not aware that the associated change [1] would be approved
> nor that you would send a warning that this is going to happen.

Wait, right. It was just the Forewarning1 [4] that was approved,
not the Forewarning2 one.

> Am I missing something?

My intention was to break it right at the branch-off.
What do I do now? Just keep it as it is?
Revert, somehow initiate the approval early and unrevert once I have one?

> [1] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2

[2] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VVLHQAWI3IQ7NRLKMUHJ27JV3V2JAFDP/
[3] https://lwn.net/Articles/887832/
[4] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1
___
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: F37 side tag after branching point

[Petr Pisar]

V Wed, Aug 24, 2022 at 03:00:23PM +0200, Iñaki Ucar napsal(a):
> On Wed, 24 Aug 2022 at 12:39, Petr Pisar  wrote:
> >
> > > So if the rawhide rebuild can be based on the result of the F37 side tag,
> > > then bootstrapping etc. is not required, and the rebuild is fast and
> > > straightforward. More so if no commits are needed.
> > >
> > This optimization is also possible.
> 
> Nice! And how would this work? It is a
> you-need-help-from-releng-possible or an option-to-koji-possible? The
> --repo-id option to "koji build" seems promising.
>
You tag each f37 build into the f38 side tag with:

$ koji tag-pkg THE_F38_TAG THE_PACKAGE_BUILD

Then you use koji "wait-repo THE_F38_TAG --build THE_PACKAGE_BUILD" to make
sure the builds are available in a build root. Then you can build the f38
packages in the f38 side tag.

But be ware that it also can be risky. The f37 packages could compile in f37
compiler flags and the f38 rebuilds could retrieve them and use. You need to
know the packages to be sure that it is safe to short-circuit the builds.

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

Ruby FTBFS due to "SHA-1 jump scare"

[Vít Ondruch]

Alexander,

Would you mind to comment on your intentions with:

https://src.fedoraproject.org/rpms/crypto-policies/c/2f33ffcfa7192037f969c6a28e092aca767a1415?branch=rawhide

which just landed in Fedora and broke Ruby test suite (even more then it 
was broken before):


https://koschei.fedoraproject.org/package/ruby

Although I know something like this was discussed and is already enabled 
in c9s, I am not aware that the associated change [1] would be approved 
nor that you would send a warning that this is going to happen.


Am I missing something?


Vít



[1] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2



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: Planning to start unifying native and mingw packages

[Daniel P . Berrangé]

On Wed, Aug 24, 2022 at 03:57:37PM +0200, Fabio Valentini wrote:
> On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé  
> wrote:
> >
> > On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:
> > > Hi
> > >
> > > Following recent discussions and to reduce the maintenance burden, I'm
> > > planning to start merging native and mingw packages. Initially, I'll be
> > > looking at these packages where I maintain both variants:
> >
> > I've done the same with all the mingw packages I maintained just
> > before Fedora 37 branched. So the following native packages now
> > just contain mingw sub-RPMs:
> >
> >  libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc
> >
> > I'm so happy to have reduced this maint burden. I see a few new mingw
> > packages pending in package review and think it'd be nice to first ask
> > the native maintainer to consider unified package, before we approve
> > any new separate mingw packages.
> >
> > Our Mingw packaging guidelines, however, exclusively describe fully
> > separated mingw packages.  So if I suggest this to a native package
> > maintainer who is not already familiar with mingw, they would be
> > right to question whether this is a desirable thing.
> >
> > IOW, I think we need to look at getting the mingw packaging docs
> > updated to promote unified packaging as an officially supported
> > (and even preferred) option, alongside separate packaging.
> 
> Sounds great.
> The Packaging Committee is looking forward to your PR ;)

I don't want to rush into doing that myself in case someone else reading
along is very enthusiastic to do the work themselves ;-P

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Planning to start unifying native and mingw packages

[Fabio Valentini]

On Wed, Aug 24, 2022 at 3:49 PM Daniel P. Berrangé  wrote:
>
> On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:
> > Hi
> >
> > Following recent discussions and to reduce the maintenance burden, I'm
> > planning to start merging native and mingw packages. Initially, I'll be
> > looking at these packages where I maintain both variants:
>
> I've done the same with all the mingw packages I maintained just
> before Fedora 37 branched. So the following native packages now
> just contain mingw sub-RPMs:
>
>  libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc
>
> I'm so happy to have reduced this maint burden. I see a few new mingw
> packages pending in package review and think it'd be nice to first ask
> the native maintainer to consider unified package, before we approve
> any new separate mingw packages.
>
> Our Mingw packaging guidelines, however, exclusively describe fully
> separated mingw packages.  So if I suggest this to a native package
> maintainer who is not already familiar with mingw, they would be
> right to question whether this is a desirable thing.
>
> IOW, I think we need to look at getting the mingw packaging docs
> updated to promote unified packaging as an officially supported
> (and even preferred) option, alongside separate packaging.

Sounds great.
The Packaging Committee is looking forward to your PR ;)

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

HEADS UP: ffmpeg 5.1 update for F37+ incoming

[Neal Gompa]

Hey all,

I'm updating ffmpeg to 5.1 to synchronize with third-party
repositories that use this version for F37+. Because there were some
failed builds from the F37 mass build due to bootstrap cycles, I'm
using this as an opportunity to clean that up too. There is also some
ELN fallout to deal with, too.

I will do this later today or tomorrow, depending on when I can make
the time for it.

Based on a repoquery, these are the reverse dependencies:

* attract-mode
* blender
* chromaprint
* indi-3rdparty-drivers
* loudgain
* notcurses
* siril

I'll rebuild those in a side-tag and propose an update.

RHBZ reference: https://bugzilla.redhat.com/2121070

-- 
真実はいつも一つ！/ 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: Planning to start unifying native and mingw packages

[Daniel P . Berrangé]

On Sun, Feb 20, 2022 at 10:13:18PM +0100, Sandro Mani wrote:
> Hi
> 
> Following recent discussions and to reduce the maintenance burden, I'm
> planning to start merging native and mingw packages. Initially, I'll be
> looking at these packages where I maintain both variants:

I've done the same with all the mingw packages I maintained just
before Fedora 37 branched. So the following native packages now
just contain mingw sub-RPMs:

 libvirt, libvirt-glib, libosinfo, osinfo-db, osinfo-db-tools, gtk-vnc

I'm so happy to have reduced this maint burden. I see a few new mingw
packages pending in package review and think it'd be nice to first ask
the native maintainer to consider unified package, before we approve
any new separate mingw packages.

Our Mingw packaging guidelines, however, exclusively describe fully
separated mingw packages.  So if I suggest this to a native package
maintainer who is not already familiar with mingw, they would be
right to question whether this is a desirable thing.

IOW, I think we need to look at getting the mingw packaging docs
updated to promote unified packaging as an officially supported
(and even preferred) option, alongside separate packaging.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: libpq-devel and postgresql-private-devel providing conflicting libpq.so symlink

[Stephan Bergmann]

On 24/08/2022 08:21, Stephan Bergmann wrote:
Seen at least on F36 x86_64:  The package 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 (built 2022-07-12) contains 
a library /usr/lib64/libreoffice/program/libpostgresql-sdbc-impllo.so 
that links against libpq (built with -lpq), so the library has



 0x0001 (NEEDED) Shared library: [libpq.so.5]


and the package requires


libpq.so.5()(64bit)
libpq.so.5(RHPG_9.6)(64bit)


satisfied by libpq-14.1-2.fc36.x86_64.

But when I scratch-rebuilt that exact same 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 yesterday 
(), the 
build apparently picked up postgresql-private-devel-14.3-2.fc36.x86_64 
rather than the expected libpq-devel-14.1-2.fc36.x86_64, so was built 
against



/usr/lib64/libpq.so -> libpq.so.private14-5.14


rather than the expected


/usr/lib64/libpq.so -> libpq.so.5.14


so the resulting 
/usr/lib64/libreoffice/program/libpostgresql-sdbc-impllo.so unexpectedly 
has


 0x0001 (NEEDED) Shared library: 
[libpq.so.private14-5]


and the package unexpectedly requires


libpq.so.private14-5()(64bit)


satisfied by postgresql-private-libs-14.3-2.fc36.x86_64.  (Which is a 
problem when trying to do a fresh libreoffice-flatpak build, which 
bundles libpq but not postgresql-private-libs.)


I'm not sure what changed between the two 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 builds (2022-07-12 and 
2022-08-23), and whether libpq-devel and postgresql-private-devel 
already conflict over /usr/lib64/libpq.so since ~forever (and that's 
expected and wanted?).  Maybe somebody has an idea?


The corresponding libreoffice.spec has


BuildRequires: pkgconfig(libpq)


and the libpq-devel and postgresql-private-devel packages apparently 
also conflict over /usr/lib64/pkgconfig/libpq.pc.  I don't know how such 
a BuildRequires is resolved exactly, but could it be that it 
deliberately chooses postgresql-private-devel now over libpq-devel 
because the latest


$ rpm -q --provides -p postgresql-private-devel-14.3-2.fc36.x86_64.rpm 
pkgconfig(libpq) = 14.3

postgresql-private-devel = 14.3-2.fc36
postgresql-private-devel(x86-64) = 14.3-2.fc36


now advertises a higher "pkgconfig(libpq) = 14.3" than the latest

$ rpm -q --provides -p libpq-devel-14.1-2.fc36.x86_64.rpm 
libpq-devel = 14.1-2.fc36

libpq-devel(x86-64) = 14.1-2.fc36
pkgconfig(libpq) = 14.1
postgresql-devel = 14.1-2.fc36


still only advertising "pkgconfig(libpq) = 14.1"?
___
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 2120625] perl-Config-Perl-V-0.34 is available

[bugzilla]

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



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


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

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120413
___
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 2120625] perl-Config-Perl-V-0.34 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Config-Perl-V-0.34-1.f
   ||c38
   ||perl-Config-Perl-V-0.34-1.f
   ||c37
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
 CC|jples...@redhat.com,|
   |mspa...@redhat.com, |
   |ppi...@redhat.com   |
Last Closed||2022-08-24 13:18:53




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2120625
___
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-Config-Perl-V] PR #1: Tests

[Jitka Plesnikova]

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

Merged pull-request:

``
Tests
``

https://src.fedoraproject.org/rpms/perl-Config-Perl-V/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Config-Perl-V] PR #1: Tests

[Jitka Plesnikova]

jplesnik opened a new pull-request against the project: `perl-Config-Perl-V` 
that you are following:
``
Tests
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Config-Perl-V/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: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 12:39, Petr Pisar  wrote:
>
> > So if the rawhide rebuild can be based on the result of the F37 side tag,
> > then bootstrapping etc. is not required, and the rebuild is fast and
> > straightforward. More so if no commits are needed.
> >
> This optimization is also possible.

Nice! And how would this work? It is a
you-need-help-from-releng-possible or an option-to-koji-possible? The
--repo-id option to "koji build" seems promising.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2119963] perl-Prima-1.66 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2022-08-24 12:38:21




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

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Prima-1.66-1.fc38




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

[Sandro]

On 23-08-2022 16:00, Sandro wrote:

I am interested in adopting the orphaned flare package[1]. It doesn't
appear to have any complicated requirements. My local build on a recent
git clone succeeded without effort.


I became aware of the package being orphaned by the announcement sent a 
couple of days ago. While flare is being orphaned, flare-engine is not.


So, I guess my next step would be to contact the current maintainer, 
Sandipan Roy aka bytehackr, and discuss with him? Both packages rely on 
the same source. I guess he would appreciate a heads up. Maybe he took 
flare-engine recently and forgot about flare.



As I'm not in the packagers group, yet, I will have to complete the
sponsoring process first. For that I am looking for a sponsor, too.


Regarding the FTBFS bug [3], it looks like the rebuild failed for the 
s390x target. Not sure, this is a desired target. Could probably just be 
disabled.


[1] https://src.fedoraproject.org/rpms/flare
[2] https://src.fedoraproject.org/rpms/flare-engine
[3] https://bugzilla.redhat.com/show_bug.cgi?id=2113227

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

[Bug 2119963] perl-Prima-1.66 is available

[bugzilla]

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



--- Comment #5 from Petr Pisar  ---
Upstream fixed the crash in a git tree.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2119963
___
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: F37 side tag after branching point

[Petr Pisar]

V Wed, Aug 24, 2022 at 10:58:00AM +0200, Iñaki Ucar napsal(a):
> On Wed, 24 Aug 2022 at 10:49, Petr Pisar  wrote:
> >
> > V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> > > Hi all,
> > >
> > > We have a new R version sitting on a side tag (f37-build-side-55653)
> > > for a few weeks now, where packages are being rebuilt as time permits.
> > > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > > this side tag could be safely merged both in F37 and rawhide when it
> > > is ready.
> > >
> > I think you can tag any package anywhere. Therefore should be possible to 
> > get
> > the same build into both Fedoras.
> >
> > However, it could be unsafe (e.g. a change in C toolchain to distribution
> > macros). To mitigate it I think you can rebuild the packages in a F38 side 
> > tag
> > without additional commits. Just follow the order which was used in F37 side
> > tag. The commits exist both in F37 and F38 git branches. F38 builds will get
> > unique release strings due to differing %dist tag.
> 
> Thanks. The main issue is that there are circular dependencies, and it
> requires bootstrapping in some cases and disabling the checks in
> others, and then another pass to reenable everything.

One can build the packages from the historical commits where the boostraping
was in effect. That's not a technical problem.

> So if the rawhide rebuild can be based on the result of the F37 side tag,
> then bootstrapping etc. is not required, and the rebuild is fast and
> straightforward. More so if no commits are needed.
>
This optimization is also possible.

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

Re: F37 side tag after branching point

[Miro Hrončok]

On 24. 08. 22 12:15, Iñaki Ucar wrote:

On Wed, 24 Aug 2022 at 12:04, Miro Hrončok  wrote:


On 24. 08. 22 10:58, Iñaki Ucar wrote:

Thanks. The main issue is that there are circular dependencies, and it
requires bootstrapping in some cases and disabling the checks in
others, and then another pass to reenable everything. So if the
rawhide rebuild can be based on the result of the F37 side tag, then
bootstrapping etc. is not required, and the rebuild is fast and
straightforward. More so if no commits are needed.


Either use the f37 builds or use the existing bootstrap commits. It is not
necessary to build from the latest commit.


How is that done? I don't see any arguments to "fedpkg build" to
specify the commit and I assumed that it uses the remote HEAD. Does it
honor the local HEAD?


I don't think it can be done by fedpkg. I use this:

koji build f37 --nowait --fail-fast 
'git+https://src.fedoraproject.org/rpms/ipsilon.git#26169c9776b8bdb62a6f3da1fe5fe6c71071502b'


--
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: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 12:04, Miro Hrončok  wrote:
>
> On 24. 08. 22 10:58, Iñaki Ucar wrote:
> > Thanks. The main issue is that there are circular dependencies, and it
> > requires bootstrapping in some cases and disabling the checks in
> > others, and then another pass to reenable everything. So if the
> > rawhide rebuild can be based on the result of the F37 side tag, then
> > bootstrapping etc. is not required, and the rebuild is fast and
> > straightforward. More so if no commits are needed.
>
> Either use the f37 builds or use the existing bootstrap commits. It is not
> necessary to build from the latest commit.

How is that done? I don't see any arguments to "fedpkg build" to
specify the commit and I assumed that it uses the remote HEAD. Does it
honor the local HEAD?

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: abipkgdiff - indirect sub-type changes

[Kevin Kofler via devel]

Orion Poplawski wrote:
> Does this break ABI?

Yes. They changed functions to take 64-bit integers instead of 32-bit ones. 
When called by code compiled against a previous version, the upper half will 
be garbage. On some architectures (depending on how exactly arguments are 
passed, but they will usually be big-endian ones), even the whole thing. 
(There, the lower half will be complete garbage, and the upper half will be 
what should be the lower half. Or in the worst case, some architectures 
might even decide to switch from register to stack passing, making the whole 
number or even also the other arguments complete garbage.)

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

Re: GNOME's Icon Development Kit icons potentially causing implicit conflicts

[Kevin Kofler via devel]

Elliott Sales de Andrade wrote:
> Icons are not code.

Even if they are compiled into a code binary as a resource file (as seem to 
be often done in this case)?

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

Re: F37 side tag after branching point

[Miro Hrončok]

On 24. 08. 22 10:58, Iñaki Ucar wrote:

Thanks. The main issue is that there are circular dependencies, and it
requires bootstrapping in some cases and disabling the checks in
others, and then another pass to reenable everything. So if the
rawhide rebuild can be based on the result of the F37 side tag, then
bootstrapping etc. is not required, and the rebuild is fast and
straightforward. More so if no commits are needed.


Either use the f37 builds or use the existing bootstrap commits. It is not 
necessary to build from the latest commit.


--
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: Pcre Deprecation (System-Wide Change proposal)

[Fabio Alessandro Locati]

On Wed, Aug 24, 2022, at 11:56, Kevin Kofler via devel wrote:
> That was exactly my point though. If nobody finds CVEs, then nobody has to 
> fix them. We can only fix what we know about, and blackhats can only attack 
> what they know about.

The fact that there are no new CVEs (and therefore fixes) does not imply that 
there are no security vulnerabilities (potentially) exploited in the wild.
-- 
Fabio Alessandro "Fale" Locati
fale.io
___
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: Pcre Deprecation (System-Wide Change proposal)

[Demi Marie Obenour]

On 8/24/22 05:56, Kevin Kofler via devel wrote:
> Daniel P. Berrangé wrote:
>> pcre will also have a drop in found CVEs simply because far fewer people
>> will be bothering to look at the old code. If no one is looking for bugs
>> then none are going to be reported :-)
> 
> That was exactly my point though. If nobody finds CVEs, then nobody has to 
> fix them. We can only fix what we know about, and blackhats can only attack 
> what they know about.

Evil hackers will not stop looking for flaws in a package just
because it is no longer supported.  The correct response is to
port the impacted packages to use PCRE2, either directly or via a
wrapper library.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
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: Pcre Deprecation (System-Wide Change proposal)

[Kevin Kofler via devel]

Lukas Javorsky wrote:
> Anyway, the main idea behind this change is to prevent any new packages
> coming to Fedora 38 to require the old pcre package and forward them to
> use the newer version of it *pcre2*.

As I have stated several times, I do not see this process as a productive or 
useful thing to do. It can prevent useful software from going into Fedora 
just because it has been written by upstream some time ago and not 
immediately packaged. It will not magically port any software to newer 
libraries, just prevent it from entering Fedora for no good reason.

To put it bluntly, I believe package deprecation should not exist or be 
allowed at all.

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

Re: F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Kevin Kofler via devel]

Daniel P. Berrangé wrote:
> pcre will also have a drop in found CVEs simply because far fewer people
> will be bothering to look at the old code. If no one is looking for bugs
> then none are going to be reported :-)

That was exactly my point though. If nobody finds CVEs, then nobody has to 
fix them. We can only fix what we know about, and blackhats can only attack 
what they know about.

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

Re: F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Lukas Javorsky]

Thank you for all of your feedback.

As Zbyszek mentioned, this change is only about the *deprecation*, not the
*retirement*.
This means that if the pcre is deprecated, no new package will be allowed
to require it. Also, it would mean that all of the existing packages will
be notified about this deprecation and will be encouraged to port to the
new pcre2 library.

However, if some package has a solid justification for not porting to the
new pcre2 package, it is fine.
In the event that this deprecation is approved, the next step will
determine whether the package will be retired completely or orphaned and
supported by some maintainers.

Anyway, the main idea behind this change is to prevent any new packages
coming to Fedora 38 to require the old pcre package and forward them to use
the newer version of it *pcre2*.

Lukas

On Wed, Aug 24, 2022 at 9:38 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Wed, Aug 24, 2022 at 05:14:33AM +0200, Kevin Kofler via devel wrote:
> > Ben Cotton wrote:
> > > == Summary ==
> > > Upstream stopped the support for the old 'pcre' package. It only
> > > supports the new 'pcre2' version, so Fedora should deprecate it so it
> > > could later be retired and removed from Fedora entirely.
> > >
> > > == Owner ==
> > > * Name: [[User:ljavorsk| Lukas Javorsky]]
> > > * Email: ljavo...@redhat.com
> >
> > This is simply a non-starter.
>
> "non-starter" is not the phrase you are looking for.
> This change is explicitly about *deprecating* the package to encourage
> packagers
> to move off the dependency and not add any new dependencies. This is
> something that we certain *can do*, and something that'll benefit the
> distro.
>
> What we do with the package two years down the road when as many
> dependencies as possible have been removed, is a separate topic, subject
> to the (at this point hypothetical) second Change proposal.
> So… hold your guns unless you have issues with *this* part, i.e.
> deprecation.
>
> > You yourself list dozens of packages using this compatibility library.
> Some
> > of those are themselves compatibility libraries (e.g., kdelibs 3 and 4)
> and
> > will never be fixed by upstream. It is entirely impractical to port them
> to
> > a completely different API. But even current leaf packages such as
> rkward
> > are in the list.
> >
> > PCRE 1 needs to remain as a fully supported compatibility library for
> the
> > foreseeable future.
> >
> > > == Detailed Description ==
> > > Upstream stopped supporting the old 'pcre' package. The 8.45 is marked
> > > as a final release and nothing else will be added/fixed in it. This
> > > may lead to some unresolved CVEs, which would have to be resolved by
> > > the maintainers. Unfortunately, due to our limited capacity, we
> > > wouldn't have the time and experience to solve this by ourselves, so
> > > we need to deprecate this package. After the deprecation is done, the
> > > very next step would be starting the [[PcreRetirement|retirement
> > > change]], so the package is removed from Fedora entirely.
> >
> > How different is the code from the pcre2 code? If it is completely
> > different, then CVEs found in pcre2 will typically not affect the legacy
> > code, and you can expect a steep drop in found CVEs with the upstream
> drop
> > of support. If, on the other hand, it is sufficiently similar for the
> CVEs
> > to apply, then the fixes can also be backported.
> >
> > In the end, my suggestion if you are unable to deal with the security
> > vulnerabilities is to simply orphan the library and let someone else
> pick it
> > up. (If nobody else does, I will, because at least 3 of my packages
> depend
> > on it.)
>
> That is always an option. I think the porting effort depends a lot on
> what parts of the pcre api are used. So let's figure out first what
> can be ported, and of the things that can't, what can be dropped.
>
> 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
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Re: GNOME's Icon Development Kit icons potentially causing implicit conflicts

[Lyes Saadi]

Le 24/08/2022 à 09:47, Vít Ondruch a écrit :> Shouldn't we have shared 
"Icon Library" package, which would solve the

conflicts?



Yes, this is what I'm also proposing, and what I think is probably the 
most painless solution. Additionally, since packages like 
gnome-control-center install icons this way, it would make it harder to 
miss the potential conflicts.


Although, I think that the Icon Library app doesn't put apps in 
categories nor does it install them system-wide. I think it would be 
easier to package Icon Development Kit itself.


Regards,
Lyes Saadi
___
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: F37 side tag after branching point

[Iñaki Ucar]

And now with the attachments... Classic.

On Wed, 24 Aug 2022 at 11:28, Iñaki Ucar  wrote:
>
> On Wed, 24 Aug 2022 at 10:59, Fabio Valentini  wrote:
> >
> > On Wed, Aug 24, 2022 at 10:39 AM Petr Pisar  wrote:
> > >
> > > V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> > > > Hi all,
> > > >
> > > > We have a new R version sitting on a side tag (f37-build-side-55653)
> > > > for a few weeks now, where packages are being rebuilt as time permits.
> > > > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > > > this side tag could be safely merged both in F37 and rawhide when it
> > > > is ready.
> > > >
> > > I think you can tag any package anywhere. Therefore should be possible to 
> > > get
> > > the same build into both Fedoras.
> > >
> > > However, it could be unsafe (e.g. a change in C toolchain to distribution
> > > macros). To mitigate it I think you can rebuild the packages in a F38 
> > > side tag
> > > without additional commits. Just follow the order which was used in F37 
> > > side
> > > tag. The commits exist both in F37 and F38 git branches. F38 builds will 
> > > get
> > > unique release strings due to differing %dist tag.
> >
> > When I was in a similar situation around the F37 branch point, releng
> > told me that while it would be *possible* for them to tag builds into
> > f38, it is possibly ill-advisable, for some of the reasons Petr
> > mentioned here, but also, the packages will get signed with the f37
> > key and not the f38 key, which will create another set of problems
> > down the line.
> >
> > Iñaki, do you have a list of packages that still needs to be rebuilt for 
> > f37?
> > I have provenpackager rights and could handle those builds for you,
>
> Thank you very much, but note that @spot (in cc) is slowly working
> through the packages, so maybe it's best to coordinate with him.
>
> > if you give me
> >
> > - name of the side tag
>
> f37-build-side-55653
>
> > - packages that still need to be rebuilt
>
> blist-37.txt attached, but note this may change if @spot sends new builds.
>
> > - which order they need to be built in (or at least how to determine an 
> > order)
>
> blist-37.txt contains batches of packages to be built in order, one
> per line. This was obtained by
>
> 1. cloning all the packages,
> 2. sed'ing the specs to set "%bcond_without bootstrap" and
> "%bcond_with checks" in those specs that contain the opposite (not
> sure if there is any other edge case),
> 3. evaluating the specs to get the BuildRequires, and finally
> 4. using these to get these dependent batches of packages.
>
> The script is in https://pagure.io/R/packaging (in R, sorry). Finally,
> I filtered out the packages that are currently in the side tag.
>
> > - what changelog message / commit message to use for the dist-git commits
>
> @spot is using just "R 4.2.1".
>
> > And for rawhide / f38, I'd need the same, but the list of *all*
> > packages that need to be built, not only the ones that are still
> > missing from f38.
>
> blist-38.txt attached. Again, one batch per line. If this rebuild
> could be based on the prior one, then there would be no need to do
> batches though.
>
> > I'll probably write a short script to handle the actual task and let
> > it run in the background today.
> >
> > Sorry for not volunteering earlier, but I'm already at my limits wrt/
> > time I can spend on Fedora.
>
> No need to apologise. On the contrary, it's very generous of you
> considering all the things you have on your plate already.
>
> --
> Iñaki Úcar



-- 
Iñaki Úcar
R-arules R-car R-mvtnorm R-ncdf4 R-NISTunits R-nws R-packrat R-parallelly 
R-pbapply R-pbdRPC R-preprocessCore R-prettyunits R-qtl R-quadprog 
R-RColorBrewer R-Rcompression R-Rcpp R-RhpcBLASctl R-Rhtslib R-RInside R-rjson 
R-rlecuyer R-RODBC R-Rsolid R-rsvg R-scatterplot3d R-sciplot R-sfsmisc R-snow 
R-sys R-tkrplot R-udunits2 R-uuid R-waveslim R-wavethresh R-widgetTools R-zoo
R-ape R-Cairo R-caTools R-foreach R-fts R-htmltools R-hunspell R-lmtest 
R-lokern R-markdown R-MatrixGenerics R-mnormt R-msm R-pbdZMQ R-plogr R-poLCA 
R-randomForest R-RcppCCTZ R-RcppDate R-rgdal R-rprintf R-S4Vectors R-sandwich 
R-statnet.common R-stringdist R-sysfonts R-tkWidgets R-webp
R-Biobase R-BiocIO R-doMC R-itertools R-mapproj R-orcutt R-RM2 R-showtextdb 
R-systemfit R-tinytex R-vcd R-whisker
R-blob R-pkgbuild R-R.cache R-R.devices R-showtext
R-doParallel R-gdata R-IRanges R-lambda.r R-timeDate
R-DelayedArray R-GenomeInfoDb R-htmlwidgets R-restfulr R-timeSeries R-XVector
R-Biostrings R-GenomicRanges R-gplots R-profvis R-xtable
R-ascii R-SummarizedExperiment
R-askpass R-bindrcpp R-cachem R-futile.logger R-igraph R-jquerylib R-mockery 
R-munsell R-parsedate R-pingr R-plyr R-presser R-R.rsp R-rematch R-repr R-rgeos 
R-simmer R-sourcetools R-tikzDevice R-tweenr R-unix R-viridisLite R-xopen R-zip
R-BiocParallel R-debugme R-IRdisplay R-listenv R-memoise R-openssl R-oskeyring 
R-prettycode R-profmem R-qpdf R-reshape R-reshape2 

Re: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 10:59, Fabio Valentini  wrote:
>
> On Wed, Aug 24, 2022 at 10:39 AM Petr Pisar  wrote:
> >
> > V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> > > Hi all,
> > >
> > > We have a new R version sitting on a side tag (f37-build-side-55653)
> > > for a few weeks now, where packages are being rebuilt as time permits.
> > > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > > this side tag could be safely merged both in F37 and rawhide when it
> > > is ready.
> > >
> > I think you can tag any package anywhere. Therefore should be possible to 
> > get
> > the same build into both Fedoras.
> >
> > However, it could be unsafe (e.g. a change in C toolchain to distribution
> > macros). To mitigate it I think you can rebuild the packages in a F38 side 
> > tag
> > without additional commits. Just follow the order which was used in F37 side
> > tag. The commits exist both in F37 and F38 git branches. F38 builds will get
> > unique release strings due to differing %dist tag.
>
> When I was in a similar situation around the F37 branch point, releng
> told me that while it would be *possible* for them to tag builds into
> f38, it is possibly ill-advisable, for some of the reasons Petr
> mentioned here, but also, the packages will get signed with the f37
> key and not the f38 key, which will create another set of problems
> down the line.
>
> Iñaki, do you have a list of packages that still needs to be rebuilt for f37?
> I have provenpackager rights and could handle those builds for you,

Thank you very much, but note that @spot (in cc) is slowly working
through the packages, so maybe it's best to coordinate with him.

> if you give me
>
> - name of the side tag

f37-build-side-55653

> - packages that still need to be rebuilt

blist-37.txt attached, but note this may change if @spot sends new builds.

> - which order they need to be built in (or at least how to determine an order)

blist-37.txt contains batches of packages to be built in order, one
per line. This was obtained by

1. cloning all the packages,
2. sed'ing the specs to set "%bcond_without bootstrap" and
"%bcond_with checks" in those specs that contain the opposite (not
sure if there is any other edge case),
3. evaluating the specs to get the BuildRequires, and finally
4. using these to get these dependent batches of packages.

The script is in https://pagure.io/R/packaging (in R, sorry). Finally,
I filtered out the packages that are currently in the side tag.

> - what changelog message / commit message to use for the dist-git commits

@spot is using just "R 4.2.1".

> And for rawhide / f38, I'd need the same, but the list of *all*
> packages that need to be built, not only the ones that are still
> missing from f38.

blist-38.txt attached. Again, one batch per line. If this rebuild
could be based on the prior one, then there would be no need to do
batches though.

> I'll probably write a short script to handle the actual task and let
> it run in the background today.
>
> Sorry for not volunteering earlier, but I'm already at my limits wrt/
> time I can spend on Fedora.

No need to apologise. On the contrary, it's very generous of you
considering all the things you have on your plate already.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 side tag after branching point

[Fabio Valentini]

On Wed, Aug 24, 2022 at 10:58 AM Iñaki Ucar  wrote:
>
> On Wed, 24 Aug 2022 at 10:49, Petr Pisar  wrote:
> >
> > V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> > > Hi all,
> > >
> > > We have a new R version sitting on a side tag (f37-build-side-55653)
> > > for a few weeks now, where packages are being rebuilt as time permits.
> > > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > > this side tag could be safely merged both in F37 and rawhide when it
> > > is ready.
> > >
> > I think you can tag any package anywhere. Therefore should be possible to 
> > get
> > the same build into both Fedoras.
> >
> > However, it could be unsafe (e.g. a change in C toolchain to distribution
> > macros). To mitigate it I think you can rebuild the packages in a F38 side 
> > tag
> > without additional commits. Just follow the order which was used in F37 side
> > tag. The commits exist both in F37 and F38 git branches. F38 builds will get
> > unique release strings due to differing %dist tag.
>
> Thanks. The main issue is that there are circular dependencies, and it
> requires bootstrapping in some cases and disabling the checks in
> others, and then another pass to reenable everything. So if the
> rawhide rebuild can be based on the result of the F37 side tag, then
> bootstrapping etc. is not required, and the rebuild is fast and
> straightforward. More so if no commits are needed.

That might be possible, I'll look into it when it comes to that.
First the f37 update needs to be finished and submitted :)

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: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 10:49, Petr Pisar  wrote:
>
> V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> > Hi all,
> >
> > We have a new R version sitting on a side tag (f37-build-side-55653)
> > for a few weeks now, where packages are being rebuilt as time permits.
> > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > this side tag could be safely merged both in F37 and rawhide when it
> > is ready.
> >
> I think you can tag any package anywhere. Therefore should be possible to get
> the same build into both Fedoras.
>
> However, it could be unsafe (e.g. a change in C toolchain to distribution
> macros). To mitigate it I think you can rebuild the packages in a F38 side tag
> without additional commits. Just follow the order which was used in F37 side
> tag. The commits exist both in F37 and F38 git branches. F38 builds will get
> unique release strings due to differing %dist tag.

Thanks. The main issue is that there are circular dependencies, and it
requires bootstrapping in some cases and disabling the checks in
others, and then another pass to reenable everything. So if the
rawhide rebuild can be based on the result of the F37 side tag, then
bootstrapping etc. is not required, and the rebuild is fast and
straightforward. More so if no commits are needed.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 side tag after branching point

[Fabio Valentini]

On Wed, Aug 24, 2022 at 10:39 AM Petr Pisar  wrote:
>
> V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> > Hi all,
> >
> > We have a new R version sitting on a side tag (f37-build-side-55653)
> > for a few weeks now, where packages are being rebuilt as time permits.
> > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > this side tag could be safely merged both in F37 and rawhide when it
> > is ready.
> >
> I think you can tag any package anywhere. Therefore should be possible to get
> the same build into both Fedoras.
>
> However, it could be unsafe (e.g. a change in C toolchain to distribution
> macros). To mitigate it I think you can rebuild the packages in a F38 side tag
> without additional commits. Just follow the order which was used in F37 side
> tag. The commits exist both in F37 and F38 git branches. F38 builds will get
> unique release strings due to differing %dist tag.

When I was in a similar situation around the F37 branch point, releng
told me that while it would be *possible* for them to tag builds into
f38, it is possibly ill-advisable, for some of the reasons Petr
mentioned here, but also, the packages will get signed with the f37
key and not the f38 key, which will create another set of problems
down the line.

Iñaki, do you have a list of packages that still needs to be rebuilt for f37?
I have provenpackager rights and could handle those builds for you, if
you give me

- name of the side tag
- packages that still need to be rebuilt
- which order they need to be built in (or at least how to determine an order)
- what changelog message / commit message to use for the dist-git commits

And for rawhide / f38, I'd need the same, but the list of *all*
packages that need to be built, not only the ones that are still
missing from f38.
I'll probably write a short script to handle the actual task and let
it run in the background today.

Sorry for not volunteering earlier, but I'm already at my limits wrt/
time I can spend on Fedora.

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: GNOME's Icon Development Kit icons potentially causing implicit conflicts

[Vít Ondruch]

Dne 24. 08. 22 v 2:55 Lyes Saadi napsal(a):

Hello devel,

I recently packaged blackbox-terminal, but, someone packaging another 
app, extension-manager noticed that his package conflicted with mine, 
and a `dnf whatprovides` later noticed that it also conflicted with 
cozy*. I soon discovered that all those apps shared icons from the 
Icon Development Kit[1] app, mostly known thanks to Icon Library[2].


Icon Library instruct developers to include these icons in a gresource 
file, basically hard coding them into the app.



Shouldn't we have shared "Icon Library" package, which would solve the 
conflicts?



Vít




OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F37 side tag after branching point

[Petr Pisar]

V Tue, Aug 23, 2022 at 08:16:00PM +0200, Iñaki Ucar napsal(a):
> Hi all,
> 
> We have a new R version sitting on a side tag (f37-build-side-55653)
> for a few weeks now, where packages are being rebuilt as time permits.
> Unfortunately, F37 is not rawhide anymore, so the question is whether
> this side tag could be safely merged both in F37 and rawhide when it
> is ready.
> 
I think you can tag any package anywhere. Therefore should be possible to get
the same build into both Fedoras.

However, it could be unsafe (e.g. a change in C toolchain to distribution
macros). To mitigate it I think you can rebuild the packages in a F38 side tag
without additional commits. Just follow the order which was used in F37 side
tag. The commits exist both in F37 and F38 git branches. F38 builds will get
unique release strings due to differing %dist tag.

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

Re: F37 side tag after branching point

[Iñaki Ucar]

On Wed, 24 Aug 2022 at 04:56, Maxwell G  wrote:
>
> On Tuesday, August 23, 2022 1:16:00 PM CDT Iñaki Ucar wrote:
> > We have a new R version sitting on a side tag (f37-build-side-55653)
> > for a few weeks now, where packages are being rebuilt as time permits.
>
> Can this perhaps be handled differently next time? I admit that I'm not
> familiar with the R ecosystem, so the answer may be no. Side tags are not
> meant to be open for this long. So far, this R rebuild has caused a lot of
> problems (see "The R stack in Rawhide is on fire"). What are the issues that
> prevent the rebuild from happening all at once?

Time and provenpackager hands. The lack of them, to be precise.

> Can it be staged in COPR to
> make sure nothing will break? Can the packages be built all at once with a
> script?

Sure, but this is additional work that, again, requires time. See above.

We are in the process of creating a SIG, a FAS group (already done),
and adding commit access to this group to all the R software, so that
more time and more hands can be invested in the future. But yet again,
this requires time, and people were a bit overloaded already. So it is
what it is for now.

> > Unfortunately, F37 is not rawhide anymore, so the question is whether
> > this side tag could be safely merged both in F37 and rawhide when it
> > is ready.
>
> I'll defer to the releng folks, but I think you should be able to merge the
> sidetag normally through the Bodhi interface, though it will be for f37 and
> not rawhide. You'll have to rebuild everything in rawhide.

We expected that much for F37, we just hoped that the latter could be avoided.

-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Aug 24, 2022 at 05:14:33AM +0200, Kevin Kofler via devel wrote:
> Ben Cotton wrote:
> > == Summary ==
> > Upstream stopped the support for the old 'pcre' package. It only
> > supports the new 'pcre2' version, so Fedora should deprecate it so it
> > could later be retired and removed from Fedora entirely.
> > 
> > == Owner ==
> > * Name: [[User:ljavorsk| Lukas Javorsky]]
> > * Email: ljavo...@redhat.com
> 
> This is simply a non-starter.

"non-starter" is not the phrase you are looking for.
This change is explicitly about *deprecating* the package to encourage packagers
to move off the dependency and not add any new dependencies. This is
something that we certain *can do*, and something that'll benefit the distro.

What we do with the package two years down the road when as many
dependencies as possible have been removed, is a separate topic, subject
to the (at this point hypothetical) second Change proposal.
So… hold your guns unless you have issues with *this* part, i.e. deprecation.

> You yourself list dozens of packages using this compatibility library. Some 
> of those are themselves compatibility libraries (e.g., kdelibs 3 and 4) and 
> will never be fixed by upstream. It is entirely impractical to port them to 
> a completely different API. But even current leaf packages such as rkward 
> are in the list.
> 
> PCRE 1 needs to remain as a fully supported compatibility library for the 
> foreseeable future.
> 
> > == Detailed Description ==
> > Upstream stopped supporting the old 'pcre' package. The 8.45 is marked
> > as a final release and nothing else will be added/fixed in it. This
> > may lead to some unresolved CVEs, which would have to be resolved by
> > the maintainers. Unfortunately, due to our limited capacity, we
> > wouldn't have the time and experience to solve this by ourselves, so
> > we need to deprecate this package. After the deprecation is done, the
> > very next step would be starting the [[PcreRetirement|retirement
> > change]], so the package is removed from Fedora entirely.
> 
> How different is the code from the pcre2 code? If it is completely 
> different, then CVEs found in pcre2 will typically not affect the legacy 
> code, and you can expect a steep drop in found CVEs with the upstream drop 
> of support. If, on the other hand, it is sufficiently similar for the CVEs 
> to apply, then the fixes can also be backported.
> 
> In the end, my suggestion if you are unable to deal with the security 
> vulnerabilities is to simply orphan the library and let someone else pick it 
> up. (If nobody else does, I will, because at least 3 of my packages depend 
> on it.)

That is always an option. I think the porting effort depends a lot on
what parts of the pcre api are used. So let's figure out first what
can be ported, and of the things that can't, what can be dropped.

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: F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Daniel P . Berrangé]

On Tue, Aug 23, 2022 at 03:42:30PM -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/PcreDeprecation
> 
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
> 
> 
> == Summary ==
> Upstream stopped the support for the old 'pcre' package. It only
> supports the new 'pcre2' version, so Fedora should deprecate it so it
> could later be retired and removed from Fedora entirely.
> 
> == Owner ==
> * Name: [[User:ljavorsk| Lukas Javorsky]]
> * Email: ljavo...@redhat.com
> 
> 
> == Detailed Description ==
> Upstream stopped supporting the old 'pcre' package. The 8.45 is marked
> as a final release and nothing else will be added/fixed in it. This
> may lead to some unresolved CVEs, which would have to be resolved by
> the maintainers. Unfortunately, due to our limited capacity, we
> wouldn't have the time and experience to solve this by ourselves, so
> we need to deprecate this package. After the deprecation is done, the
> very next step would be starting the [[PcreRetirement|retirement
> change]], so the package is removed from Fedora entirely.
> 
> The new 'pcre2' package is out for more than 7 years now and most of
> the packages have already been ported to its redefined API.
> [https://lists.exim.org/lurker/message/20150105.162835.0666407a.en.html
> Mail] about the changes in the pcre2.

snip

> == Benefit to Fedora ==
> Fedora shouldn't support unsupported packages. 

That's an overly broad statement that does not reflect any Fedora
rule / guideline on package inclusion.

Only version large projects have stable maint streams of their
releases, most upstreams only "support" the most recent release
they've made. IOW if the distro isn't shipping the most recent
release then it is effectively shipping unsupported packages.

For Fedora at least if a maintainer frequently rebases to new
releases, they only end up supporting an unsupported package
for upto about 1 year (two stable releases). RHEL is much worse,
as by the time a RHEL release goes EOL, you can consider the
vast majority of software to be "unsupported" from the POV of
the upstream projects.

IOW, it is reasonable to say that one of the core jobs of a
distro [maintainer] is often to provide support for a package
that upstream no longer supports.


The issue is really about how long the distro maintainer is
willing to prolong that effort on a case by case basis.

Not wishing to support multiple versions of a package in
parallel is a reasonable desire for a single maintainer,
to reduce their workload. It is not inherantly wrong for
Fedora more generally though to want to ship and support
something that upstream has stopped supporting. There
just needs to be some use case for it to exist, and a
maintainer willing todo the work.

> versions fork from Fedora, it could lead to less secure RHEL as well.
> By deprecating this package, we will send the message to the
> maintainers that their packages should port to new pcre2 package and
> any new package would have to use only new and supported pcre2
> version.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Pcre Deprecation (System-Wide Change proposal)

[Daniel P . Berrangé]

On Wed, Aug 24, 2022 at 05:14:33AM +0200, Kevin Kofler via devel wrote:
> Ben Cotton wrote:
> > == Summary ==
> > Upstream stopped the support for the old 'pcre' package. It only
> > supports the new 'pcre2' version, so Fedora should deprecate it so it
> > could later be retired and removed from Fedora entirely.
> > 
> > == Owner ==
> > * Name: [[User:ljavorsk| Lukas Javorsky]]
> > * Email: ljavo...@redhat.com
> 
> This is simply a non-starter.
> 
> You yourself list dozens of packages using this compatibility library. Some 
> of those are themselves compatibility libraries (e.g., kdelibs 3 and 4) and 
> will never be fixed by upstream. It is entirely impractical to port them to 
> a completely different API. But even current leaf packages such as rkward 
> are in the list.
> 
> PCRE 1 needs to remain as a fully supported compatibility library for the 
> foreseeable future.
> 
> > == Detailed Description ==
> > Upstream stopped supporting the old 'pcre' package. The 8.45 is marked
> > as a final release and nothing else will be added/fixed in it. This
> > may lead to some unresolved CVEs, which would have to be resolved by
> > the maintainers. Unfortunately, due to our limited capacity, we
> > wouldn't have the time and experience to solve this by ourselves, so
> > we need to deprecate this package. After the deprecation is done, the
> > very next step would be starting the [[PcreRetirement|retirement
> > change]], so the package is removed from Fedora entirely.
> 
> How different is the code from the pcre2 code? If it is completely 
> different, then CVEs found in pcre2 will typically not affect the legacy 
> code, and you can expect a steep drop in found CVEs with the upstream drop 
> of support. If, on the other hand, it is sufficiently similar for the CVEs 
> to apply, then the fixes can also be backported.

pcre will also have a drop in found CVEs simply because far fewer people
will be bothering to look at the old code. If no one is looking for bugs
then none are going to be reported :-) The number of CVEs (fixed or not)
as a metric on its own, tells us little about the security quality of any
package.

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

libpq-devel and postgresql-private-devel providing conflicting libpq.so symlink

[Stephan Bergmann]

Seen at least on F36 x86_64:  The package 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 (built 2022-07-12) contains 
a library /usr/lib64/libreoffice/program/libpostgresql-sdbc-impllo.so 
that links against libpq (built with -lpq), so the library has



 0x0001 (NEEDED) Shared library: [libpq.so.5]


and the package requires


libpq.so.5()(64bit)
libpq.so.5(RHPG_9.6)(64bit)


satisfied by libpq-14.1-2.fc36.x86_64.

But when I scratch-rebuilt that exact same 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 yesterday 
(), the 
build apparently picked up postgresql-private-devel-14.3-2.fc36.x86_64 
rather than the expected libpq-devel-14.1-2.fc36.x86_64, so was built 
against



/usr/lib64/libpq.so -> libpq.so.private14-5.14


rather than the expected


/usr/lib64/libpq.so -> libpq.so.5.14


so the resulting 
/usr/lib64/libreoffice/program/libpostgresql-sdbc-impllo.so unexpectedly has



 0x0001 (NEEDED) Shared library: [libpq.so.private14-5]


and the package unexpectedly requires


libpq.so.private14-5()(64bit)


satisfied by postgresql-private-libs-14.3-2.fc36.x86_64.  (Which is a 
problem when trying to do a fresh libreoffice-flatpak build, which 
bundles libpq but not postgresql-private-libs.)


I'm not sure what changed between the two 
libreoffice-postgresql-7.3.4.2-4.fc36.x86_64 builds (2022-07-12 and 
2022-08-23), and whether libpq-devel and postgresql-private-devel 
already conflict over /usr/lib64/libpq.so since ~forever (and that's 
expected and wanted?).  Maybe somebody has an idea?

___
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