Why should $ORIGIN runpaths appear first?

[Orion Poplawski]

vtk is generating the following rpaths errors like this:

ERROR   0008: file 
'/usr/lib64/mpich/lib/vtk/libvtkFiltersParallelGeometryJava.so' contains 
the $ORIGIN runpath specifier at the wrong position in 
[/usr/lib64/mpich/lib:$ORIGIN:$ORIGIN/../]


The notes on the errors state:

*0x0008 ... the special '$ORIGIN' RPATHs are appearing after other

*   RPATHs; this is just a minor issue but usually unwanted


Can someone explain to me why it is unwanted?  Why should $ORIGIN RPATHs 
appear first?


In this particular case I don't feel concerned with ignoring the error 
because the two paths appear to be (mostly) equivalent to me, but I'm 
curious about the error.


I believe the paths come about from:

  if (UNIX)
if (APPLE)
  set(_vtk_java_origin_rpath_prefix
"@loader_path")
else ()
  set(_vtk_java_origin_rpath_prefix
"$ORIGIN")
endif ()

list(APPEND CMAKE_INSTALL_RPATH
  # For sibling wrapped modules.
  "${_vtk_java_origin_rpath_prefix}")

if (DEFINED _vtk_java_LIBRARY_DESTINATION AND DEFINED 
_vtk_java_JNILIB_DESTINATION)

  file(RELATIVE_PATH _vtk_java_relpath
"/prefix/${_vtk_java_JNILIB_DESTINATION}"
"/prefix/${_vtk_java_LIBRARY_DESTINATION}")

  list(APPEND CMAKE_INSTALL_RPATH
# For libraries.
"${_vtk_java_origin_rpath_prefix}/${_vtk_java_relpath}")
endif ()
  endif ()


So I could submit a patch changing "APPEND" to "PREPEND", but other than 
avoiding this error I don't know why this would be preferred.


Thanks,
  Orion

--
Orion Poplawski
he/him/his - surely the least important thing about me
Manager of NWRA Technical Systems  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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Unsolicited kernel 5.13 RC1 feedback

[Richard Shaw]

After reading the Phoronic's article about the AMD improvements baked in
the 5.15 kernel I decided to give it a try on my F34 desktop.

Bootup was OK but after logging in I saw some small screen corruption on my
secondary monitor but Gnome still logged in fine. But after it fully loaded
(showing the menu at the bottom) the screen went blank and did not recover.

I tried going to a terminal and switching from graphical to command line
and back and logged in again but it kicked me back to the login screen.

Looking forward to the improvements when they're ready as I have both AMD
CPU and GPU.

Thanks,
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

New package review - help needed from experienced Python maintainer(s)

[Michal Schorm]

Hello,

I am a reviewer of a new Python package. [1]
As I am far from being proficient, I seek another pair of eyes, a
second opinion.

I am an experienced packager, I am just new to Python packaging specifics.
I'm looking for someone who will be able to help both the newcomer who
submitted the package and me to learn Python packaging.

Would you please someone join me and review my review? [1]


[1] https://bugzilla.redhat.com/show_bug.cgi?id=2003700

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

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

Fedora-IoT-34-20210916.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/15 (aarch64)

Old failures (same test failed in Fedora-IoT-34-20210912.0):

ID: 986477  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/986477

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-34-20210912.0):

ID: 986458  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/986458

Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.19 to 0.41
Previous test data: https://openqa.fedoraproject.org/tests/978912#downloads
Current test data: https://openqa.fedoraproject.org/tests/986456#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.61 to 0.50
Previous test data: https://openqa.fedoraproject.org/tests/978927#downloads
Current test data: https://openqa.fedoraproject.org/tests/986471#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Pre-release EPEL

[Thomas Stephen Lee]

On Thu, Sep 16, 2021 at 8:21 PM Troy Dawson  wrote:
>
> EPEL Next[1][2] is meant for machines running CentOS Stream.
> We currently have epel8-next, and are working on getting epel9-next setup so 
> that maintainers can build on it.
> Technically epel9-next will be a "Pre-Release" of epel9, but saying it is a 
> "pre-release" implies that it will go away.
> epel9-next will not go away when epel9 is released, but will continue to be 
> for machines running CentOS Stream 9
>
> Brought to you by the EPEL ELves
>
> [1] - https://docs.fedoraproject.org/en-US/epel/#what_is_epel_next
> [2] - https://docs.fedoraproject.org/en-US/epel/epel-about-next/
>
> On Thu, Sep 16, 2021 at 7:30 AM Stephen Gallagher  wrote:
>>
>> On Thu, Sep 16, 2021 at 10:11 AM Neal Gompa  wrote:
>> >
>> > On Thu, Sep 16, 2021 at 9:38 AM Thomas Stephen Lee  
>> > wrote:
>> > >
>> > > Hi,
>> > >
>> > > Thanks to people on the CentOS mailing list.
>> > > We managed to get CentOS Stream 9 pre-release with updates working on a 
>> > > VM.
>> > > Is there also a pre-release version of EPEL 9 we can use?
>> > >
>> >
>> > Not just yet, I'm hoping that'll be soon...
>>
>> The EPELves are working as hard as they can, stay tuned!
>> ___
>> 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 on the list, report it: 
>> https://pagure.io/fedora-infrastructure
>
> ___

We will wait.
Keep up the excellent work. 

Thanks

---
Lee
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9

[Leon Fauster]

On 16.09.21 19:47, Kevin Fenzi wrote:

On Thu, Sep 16, 2021 at 08:02:08AM -0700, Toshio Kuratomi wrote:

I believe ansible-core includes a "dependency manager" depending on your
definition.  The ansible-galaxy command in ansible-core can install ansible
collections so that's you can install modules that you may need.

It is similar in scope to pip, rubygem, cargo, or any other of the language
package installers.

It does not resolve based on what modules/plugins are used in your
playbooks but it will resolve dependencies between collection dependencies
if needed (and those deps were properly listed).

I know that Nirik has plans to get newer ansible packages into epel which
provide an all-in-one experience by installing about 75 collections which
give you an experience similar what was included in ansible-2.9 but I'll
let him speak to how he wants to do that.


Yeah.

For EPEL9, I hope to:
* Make a 'ansible' package thats the collections in upstream 'ansible',
  minus any collections that are packaged seperately (either in rhel9 or
epel9) and a 'ansible' metapackage.
* Have that 'ansible' metapackage require all those collections and 
ansible-core, so
when someone does 'dnf install ansible' they get hopefully pretty
close to what upstream ansible is now.

I'm not sure if there will be problems with that yet tho. ;)

I'm hoping to basically do this for Fedora 36, so I should know more
after that.



That would be amazing! Is it in rawhide already?

Thanks for your hard work.

--
Leon
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Miro Hrončok]

On 16. 09. 21 23:26, Neal Gompa wrote:

On Thu, Sep 16, 2021 at 5:24 PM Miro Hrončok  wrote:


On 16. 09. 21 22:03, Neal Gompa wrote:

On Thu, Sep 16, 2021 at 4:02 PM Miro Hrončok  wrote:


On 16. 09. 21 21:43, Fabio Valentini wrote:

For exmple, if I remember correctly, mozilla-openh264 / gstreamer
support for it are installed as weak dependencies with post-GA package
updates.


Why exactly is this a problem?



Because it will not happen anymore. We need a new way to trigger its
installation post-install.


Oh. We don't have them installed on the media, but we want them to be pulled in
on upgrades? Is there some legal requirement that forbids us to have them
installed by default directly?



Yes. The patent license for H.264 (AVC) for use with OpenH264 is only
conveyed when distributed by Cisco, which we do through the RPM
repository hosted by them.


Thanks for refreshing my memory.

We could include a meta-package in the default installation, which Recommends 
the Cisco package on GA but is switched to Requires in a 0-day update.


--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Neal Gompa]

On Thu, Sep 16, 2021 at 5:24 PM Miro Hrončok  wrote:
>
> On 16. 09. 21 22:03, Neal Gompa wrote:
> > On Thu, Sep 16, 2021 at 4:02 PM Miro Hrončok  wrote:
> >>
> >> On 16. 09. 21 21:43, Fabio Valentini wrote:
> >>> For exmple, if I remember correctly, mozilla-openh264 / gstreamer
> >>> support for it are installed as weak dependencies with post-GA package
> >>> updates.
> >>
> >> Why exactly is this a problem?
> >>
> >
> > Because it will not happen anymore. We need a new way to trigger its
> > installation post-install.
>
> Oh. We don't have them installed on the media, but we want them to be pulled 
> in
> on upgrades? Is there some legal requirement that forbids us to have them
> installed by default directly?
>

Yes. The patent license for H.264 (AVC) for use with OpenH264 is only
conveyed when distributed by Cisco, which we do through the RPM
repository hosted by them.



--
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Miro Hrončok]

On 16. 09. 21 22:03, Neal Gompa wrote:

On Thu, Sep 16, 2021 at 4:02 PM Miro Hrončok  wrote:


On 16. 09. 21 21:43, Fabio Valentini wrote:

For exmple, if I remember correctly, mozilla-openh264 / gstreamer
support for it are installed as weak dependencies with post-GA package
updates.


Why exactly is this a problem?



Because it will not happen anymore. We need a new way to trigger its
installation post-install.


Oh. We don't have them installed on the media, but we want them to be pulled in 
on upgrades? Is there some legal requirement that forbids us to have them 
installed by default directly?


--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Neal Gompa]

On Thu, Sep 16, 2021 at 4:02 PM Miro Hrončok  wrote:
>
> On 16. 09. 21 21:43, Fabio Valentini wrote:
> > For exmple, if I remember correctly, mozilla-openh264 / gstreamer
> > support for it are installed as weak dependencies with post-GA package
> > updates.
>
> Why exactly is this a problem?
>

Because it will not happen anymore. We need a new way to trigger its
installation post-install.



-- 
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Miro Hrončok]

On 16. 09. 21 21:43, Fabio Valentini wrote:

For exmple, if I remember correctly, mozilla-openh264 / gstreamer
support for it are installed as weak dependencies with post-GA package
updates.


Why exactly is this a problem?

--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Fabio Valentini]

On Thu, Sep 16, 2021 at 9:22 PM Neal Gompa  wrote:
>
> On Thu, Sep 16, 2021 at 3:18 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
> >
> >
> > == Summary ==
> > exclude_from_weak_autodetect enables autodetection of unmet weak
> > dependencies (Recommends or Supplements) of installed packages and
> > blocks installation of packages satisfying already unmet dependencies.
> > In other words: When you don't have the recommended package installed,
> > it won't be automatically installed with future upgrades of the
> > recommending package.
> >
> >
> > == Owner ==
> > * Name: [[User:jmracek| Jaroslav Mracek]]
> > * Email: jmra...@redhat.com
> >
> >
> > == Detailed Description ==
> > The feature is designed to prevent an install of removed weak
> > dependencies from the system by users and to not install weak
> > dependencies missing after system deployment. It will change the
> > behavior of DNF, microdnf, and PackageKit. The feature will be
> > backported to all Fedoras, but in default, the feature will be off.
> > Additional information: https://bugzilla.redhat.com/show_bug.cgi?id=1699672
> >
> > The default value for exclude_from_weak_autodetect configuration can
> > be overridden in `/etc/dnf/dnf.conf`
> >
> >
> > == Feedback ==
> > The feature was requested by [[User:Churchyard|Miro Hrončok]] and
> > supported by many others: See
> > [https://bugzilla.redhat.com/show_bug.cgi?id=1699672 rhbz#1699672] for
> > more feedback.
> >
> > == Benefit to Fedora ==
> > After the installation of a fresh system, the first upgrade will not
> > install a lot of weak dependencies. Some of them were excluded from
> > the kick-start installation set for good reasons (security, image
> > size, minimal functional set, ...), but after the first update, all
> > weak dependencies are installed, therefore some features of deployment
> > simply disappear.
> >
> >
> > == Scope ==
> > * Proposal owners:
> > ** The feature is ready in Pull Request -
> > https://github.com/rpm-software-management/libdnf/pull/1279
> > ** PRs only wait for a release of libsolv
> > ** The Feature will be enabled in upstream as default, therefore from
> > Fedora 36, we start to release libdnf without a revert patch of
> > default in comparison to upstream.
> >
> > * Other developers: The change requires a new release of libsolv.
> >
> > * Release engineering:
> > * Policies and guidelines: A packaging guideline should be added that
> > discourages or forbids weak dependencies on fully versioned
> > (sub)packages (see
> > [https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c44 the
> > details]).
> > * Trademark approval: N/A (not needed for this Change)
> > * Alignment with Objectives:
> >
> > == Upgrade/compatibility impact ==
> > No manual changes will be required. After the libdnf update, this
> > feature will be on by default.
> >
> >
> > == How To Test ==
> > 1. Install package without satisfied weak dependencies
> > 2. Upgrade the upgrade. With exclude_from_weak_autodetect=true, it
> > will not install weak dependencies of already installed packages. With
> > exclude_from_weak_autodetect=false, weak dependencies will be
> > installed during upgrades.
> >
> >
> > == User Experience ==
> > The change in default will help to keep some values for particular
> > deployments (a minimal system will be still minimal without disabling
> > weak dependencies).
> > Users will be able to remove particular weak dependencies and they
> > will be not installed on the first upgrade.
> > In case when the feature will not work according to the user
> > expectation it can be switched off in the dnf configuration file.
> >
> >
> > == Dependencies ==
> > libsolv - Required code changes are already in the libsolv upstream.
> > We only wait for the next libsolv release.
> >
> >
> > == Contingency Plan ==
> >
> > There are no external dependencies, therefore we can easily postpone
> > the feature and the change of default behavior.
> >
> > * Contingency mechanism: (What to do?  Who will do it?)
> > * Contingency deadline: beta freeze
> > * Blocks release? No
> >
> > == Documentation ==
> > The feature will be documented in dnf man pages.
> >
>
> Woot! I'm looking forward to this feature!

I second that, I'm looking forward to this.

However, we probably need to adapt some stuff if this is enabled by
default, because some things have abused the current behavior.
For exmple, if I remember correctly, mozilla-openh264 / gstreamer
support for it are installed as weak dependencies with post-GA package
updates.

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 

Re: Self Introduction: Eric Curtin

[Neal Gompa]

On Thu, Sep 16, 2021 at 3:04 PM Eric Curtin  wrote:
>
> Hi Guys,
>
> As per:
>
> https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/
>
> here is my introduction. I am the upstream maintainer of inotify-tools
> and recent hire at Red Hat. I would like to join the Fedora Package
> Maintainers.
>

Welcome to Fedora! :)



-- 
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Neal Gompa]

On Thu, Sep 16, 2021 at 3:18 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect
>
>
> == Summary ==
> exclude_from_weak_autodetect enables autodetection of unmet weak
> dependencies (Recommends or Supplements) of installed packages and
> blocks installation of packages satisfying already unmet dependencies.
> In other words: When you don't have the recommended package installed,
> it won't be automatically installed with future upgrades of the
> recommending package.
>
>
> == Owner ==
> * Name: [[User:jmracek| Jaroslav Mracek]]
> * Email: jmra...@redhat.com
>
>
> == Detailed Description ==
> The feature is designed to prevent an install of removed weak
> dependencies from the system by users and to not install weak
> dependencies missing after system deployment. It will change the
> behavior of DNF, microdnf, and PackageKit. The feature will be
> backported to all Fedoras, but in default, the feature will be off.
> Additional information: https://bugzilla.redhat.com/show_bug.cgi?id=1699672
>
> The default value for exclude_from_weak_autodetect configuration can
> be overridden in `/etc/dnf/dnf.conf`
>
>
> == Feedback ==
> The feature was requested by [[User:Churchyard|Miro Hrončok]] and
> supported by many others: See
> [https://bugzilla.redhat.com/show_bug.cgi?id=1699672 rhbz#1699672] for
> more feedback.
>
> == Benefit to Fedora ==
> After the installation of a fresh system, the first upgrade will not
> install a lot of weak dependencies. Some of them were excluded from
> the kick-start installation set for good reasons (security, image
> size, minimal functional set, ...), but after the first update, all
> weak dependencies are installed, therefore some features of deployment
> simply disappear.
>
>
> == Scope ==
> * Proposal owners:
> ** The feature is ready in Pull Request -
> https://github.com/rpm-software-management/libdnf/pull/1279
> ** PRs only wait for a release of libsolv
> ** The Feature will be enabled in upstream as default, therefore from
> Fedora 36, we start to release libdnf without a revert patch of
> default in comparison to upstream.
>
> * Other developers: The change requires a new release of libsolv.
>
> * Release engineering:
> * Policies and guidelines: A packaging guideline should be added that
> discourages or forbids weak dependencies on fully versioned
> (sub)packages (see
> [https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c44 the
> details]).
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives:
>
> == Upgrade/compatibility impact ==
> No manual changes will be required. After the libdnf update, this
> feature will be on by default.
>
>
> == How To Test ==
> 1. Install package without satisfied weak dependencies
> 2. Upgrade the upgrade. With exclude_from_weak_autodetect=true, it
> will not install weak dependencies of already installed packages. With
> exclude_from_weak_autodetect=false, weak dependencies will be
> installed during upgrades.
>
>
> == User Experience ==
> The change in default will help to keep some values for particular
> deployments (a minimal system will be still minimal without disabling
> weak dependencies).
> Users will be able to remove particular weak dependencies and they
> will be not installed on the first upgrade.
> In case when the feature will not work according to the user
> expectation it can be switched off in the dnf configuration file.
>
>
> == Dependencies ==
> libsolv - Required code changes are already in the libsolv upstream.
> We only wait for the next libsolv release.
>
>
> == Contingency Plan ==
>
> There are no external dependencies, therefore we can easily postpone
> the feature and the change of default behavior.
>
> * Contingency mechanism: (What to do?  Who will do it?)
> * Contingency deadline: beta freeze
> * Blocks release? No
>
> == Documentation ==
> The feature will be documented in dnf man pages.
>

Woot! I'm looking forward to this feature!




--
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect


== Summary ==
exclude_from_weak_autodetect enables autodetection of unmet weak
dependencies (Recommends or Supplements) of installed packages and
blocks installation of packages satisfying already unmet dependencies.
In other words: When you don't have the recommended package installed,
it won't be automatically installed with future upgrades of the
recommending package.


== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com


== Detailed Description ==
The feature is designed to prevent an install of removed weak
dependencies from the system by users and to not install weak
dependencies missing after system deployment. It will change the
behavior of DNF, microdnf, and PackageKit. The feature will be
backported to all Fedoras, but in default, the feature will be off.
Additional information: https://bugzilla.redhat.com/show_bug.cgi?id=1699672

The default value for exclude_from_weak_autodetect configuration can
be overridden in `/etc/dnf/dnf.conf`


== Feedback ==
The feature was requested by [[User:Churchyard|Miro Hrončok]] and
supported by many others: See
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672 rhbz#1699672] for
more feedback.

== Benefit to Fedora ==
After the installation of a fresh system, the first upgrade will not
install a lot of weak dependencies. Some of them were excluded from
the kick-start installation set for good reasons (security, image
size, minimal functional set, ...), but after the first update, all
weak dependencies are installed, therefore some features of deployment
simply disappear.


== Scope ==
* Proposal owners:
** The feature is ready in Pull Request -
https://github.com/rpm-software-management/libdnf/pull/1279
** PRs only wait for a release of libsolv
** The Feature will be enabled in upstream as default, therefore from
Fedora 36, we start to release libdnf without a revert patch of
default in comparison to upstream.

* Other developers: The change requires a new release of libsolv.

* Release engineering:
* Policies and guidelines: A packaging guideline should be added that
discourages or forbids weak dependencies on fully versioned
(sub)packages (see
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c44 the
details]).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
No manual changes will be required. After the libdnf update, this
feature will be on by default.


== How To Test ==
1. Install package without satisfied weak dependencies
2. Upgrade the upgrade. With exclude_from_weak_autodetect=true, it
will not install weak dependencies of already installed packages. With
exclude_from_weak_autodetect=false, weak dependencies will be
installed during upgrades.


== User Experience ==
The change in default will help to keep some values for particular
deployments (a minimal system will be still minimal without disabling
weak dependencies).
Users will be able to remove particular weak dependencies and they
will be not installed on the first upgrade.
In case when the feature will not work according to the user
expectation it can be switched off in the dnf configuration file.


== Dependencies ==
libsolv - Required code changes are already in the libsolv upstream.
We only wait for the next libsolv release.


== Contingency Plan ==

There are no external dependencies, therefore we can easily postpone
the feature and the change of default behavior.

* Contingency mechanism: (What to do?  Who will do it?)
* Contingency deadline: beta freeze
* Blocks release? No

== Documentation ==
The feature will be documented in dnf man pages.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

F36 Change: Enable exclude_from_weak_autodetect by default in LIBDNF (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect


== Summary ==
exclude_from_weak_autodetect enables autodetection of unmet weak
dependencies (Recommends or Supplements) of installed packages and
blocks installation of packages satisfying already unmet dependencies.
In other words: When you don't have the recommended package installed,
it won't be automatically installed with future upgrades of the
recommending package.


== Owner ==
* Name: [[User:jmracek| Jaroslav Mracek]]
* Email: jmra...@redhat.com


== Detailed Description ==
The feature is designed to prevent an install of removed weak
dependencies from the system by users and to not install weak
dependencies missing after system deployment. It will change the
behavior of DNF, microdnf, and PackageKit. The feature will be
backported to all Fedoras, but in default, the feature will be off.
Additional information: https://bugzilla.redhat.com/show_bug.cgi?id=1699672

The default value for exclude_from_weak_autodetect configuration can
be overridden in `/etc/dnf/dnf.conf`


== Feedback ==
The feature was requested by [[User:Churchyard|Miro Hrončok]] and
supported by many others: See
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672 rhbz#1699672] for
more feedback.

== Benefit to Fedora ==
After the installation of a fresh system, the first upgrade will not
install a lot of weak dependencies. Some of them were excluded from
the kick-start installation set for good reasons (security, image
size, minimal functional set, ...), but after the first update, all
weak dependencies are installed, therefore some features of deployment
simply disappear.


== Scope ==
* Proposal owners:
** The feature is ready in Pull Request -
https://github.com/rpm-software-management/libdnf/pull/1279
** PRs only wait for a release of libsolv
** The Feature will be enabled in upstream as default, therefore from
Fedora 36, we start to release libdnf without a revert patch of
default in comparison to upstream.

* Other developers: The change requires a new release of libsolv.

* Release engineering:
* Policies and guidelines: A packaging guideline should be added that
discourages or forbids weak dependencies on fully versioned
(sub)packages (see
[https://bugzilla.redhat.com/show_bug.cgi?id=1699672#c44 the
details]).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:

== Upgrade/compatibility impact ==
No manual changes will be required. After the libdnf update, this
feature will be on by default.


== How To Test ==
1. Install package without satisfied weak dependencies
2. Upgrade the upgrade. With exclude_from_weak_autodetect=true, it
will not install weak dependencies of already installed packages. With
exclude_from_weak_autodetect=false, weak dependencies will be
installed during upgrades.


== User Experience ==
The change in default will help to keep some values for particular
deployments (a minimal system will be still minimal without disabling
weak dependencies).
Users will be able to remove particular weak dependencies and they
will be not installed on the first upgrade.
In case when the feature will not work according to the user
expectation it can be switched off in the dnf configuration file.


== Dependencies ==
libsolv - Required code changes are already in the libsolv upstream.
We only wait for the next libsolv release.


== Contingency Plan ==

There are no external dependencies, therefore we can easily postpone
the feature and the change of default behavior.

* Contingency mechanism: (What to do?  Who will do it?)
* Contingency deadline: beta freeze
* Blocks release? No

== Documentation ==
The feature will be documented in dnf man pages.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Self Introduction: Bruno Larsen

[Bruno Larsen]

Hello!

I have been recently hired to help maintaining the GDB package. I have a bit of 
experience with open source development, having contributed for a few month to 
the QEMU project. I am very excited to help in the near future!

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

Fedora Linux 35 Beta is NO-GO

[Ben Cotton]

Due to outstanding blocker bugs, we do not have an F35 Beta RC. As a
result, F35 Beta is NO-GO by default and tomorrow's Go/No-Go meeting
is cancelled.

The next Fedora Linux 35 Beta Go/No-Go meeting[1] will be held at 1700
UTC on Thursday 23 September in #fedora-meeting. We will aim for the
"target date #2" milestone of 28 September. The release schedule[2]
has been updated accordingly. This change does not impact the final
release date.

[1] https://calendar.fedoraproject.org/Fedora%20release/2021/9/23/#m10064
[2] https://fedorapeople.org/groups/schedule/f-35/f-35-key-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.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-announce@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Self Introduction: Eric Curtin

[Eric Curtin]

Hi Guys,

As per:

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

here is my introduction. I am the upstream maintainer of inotify-tools
and recent hire at Red Hat. I would like to join the Fedora Package
Maintainers.

Is mise le meas/Regards,

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

[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9

[Kevin Fenzi]

On Thu, Sep 16, 2021 at 08:18:30PM +0200, Leon Fauster wrote:
> On 16.09.21 19:47, Kevin Fenzi wrote:
> > On Thu, Sep 16, 2021 at 08:02:08AM -0700, Toshio Kuratomi wrote:
> > > I believe ansible-core includes a "dependency manager" depending on your
> > > definition.  The ansible-galaxy command in ansible-core can install 
> > > ansible
> > > collections so that's you can install modules that you may need.
> > > 
> > > It is similar in scope to pip, rubygem, cargo, or any other of the 
> > > language
> > > package installers.
> > > 
> > > It does not resolve based on what modules/plugins are used in your
> > > playbooks but it will resolve dependencies between collection dependencies
> > > if needed (and those deps were properly listed).
> > > 
> > > I know that Nirik has plans to get newer ansible packages into epel which
> > > provide an all-in-one experience by installing about 75 collections which
> > > give you an experience similar what was included in ansible-2.9 but I'll
> > > let him speak to how he wants to do that.
> > 
> > Yeah.
> > 
> > For EPEL9, I hope to:
> > * Make a 'ansible' package thats the collections in upstream 'ansible',
> >   minus any collections that are packaged seperately (either in rhel9 or
> > epel9) and a 'ansible' metapackage.
> > * Have that 'ansible' metapackage require all those collections and 
> > ansible-core, so
> > when someone does 'dnf install ansible' they get hopefully pretty
> > close to what upstream ansible is now.
> > 
> > I'm not sure if there will be problems with that yet tho. ;)
> > 
> > I'm hoping to basically do this for Fedora 36, so I should know more
> > after that.
> 
> 
> That would be amazing! Is it in rawhide already?
> 
> Thanks for your hard work.

ansible-core is, but not the collections meta. Right now in rawhide
'ansible' is still 'ansible classic/2.9.x'

kevin


signature.asc
Description: PGP signature
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9

[Leon Fauster]

On 16.09.21 14:22, Josh Boyer wrote:

On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi  wrote:


Just a heads up that ansible-core (the engine part of ansible) is now in
CentOS stream 9:

https://gitlab.com/redhat/centos-stream/rpms/ansible-core

Note that this is the engine, you will likely want to install
collections for modules and roles, etc.


For those that might not have followed how Ansible has been
refactored, take a look at
https://www.ansible.com/blog/ansible-3.0.0-qa

ansible-core is the lowest level of the ansible stack and does not
include many of the modules and plugins that those using ansible
engine (ansible-2.9) might be used to.  As Kevin said, you will almost
certainly need additional modules/plugins not provided by
ansible-core.



Out of curiosity

Does CS9 provide additional (sub)packages to extend the functionality?

Right now EPEL8 provide the the full stack based on ansible 2.9.

Will EPEL9 provide such packages to provide additional modules/plugins?

And more a ansible question: Does ansible3 provide a dependencies 
manager as consequence now?


--

Thanks
Leon






___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9

[Kevin Fenzi]

On Thu, Sep 16, 2021 at 08:02:08AM -0700, Toshio Kuratomi wrote:
> I believe ansible-core includes a "dependency manager" depending on your
> definition.  The ansible-galaxy command in ansible-core can install ansible
> collections so that's you can install modules that you may need.
> 
> It is similar in scope to pip, rubygem, cargo, or any other of the language
> package installers.
> 
> It does not resolve based on what modules/plugins are used in your
> playbooks but it will resolve dependencies between collection dependencies
> if needed (and those deps were properly listed).
> 
> I know that Nirik has plans to get newer ansible packages into epel which
> provide an all-in-one experience by installing about 75 collections which
> give you an experience similar what was included in ansible-2.9 but I'll
> let him speak to how he wants to do that.

Yeah. 

For EPEL9, I hope to:
* Make a 'ansible' package thats the collections in upstream 'ansible',
 minus any collections that are packaged seperately (either in rhel9 or
epel9) and a 'ansible' metapackage.
* Have that 'ansible' metapackage require all those collections and 
ansible-core, so
when someone does 'dnf install ansible' they get hopefully pretty
close to what upstream ansible is now.

I'm not sure if there will be problems with that yet tho. ;) 

I'm hoping to basically do this for Fedora 36, so I should know more
after that. 

kevin
--
> 
> -Toshio
> 
> On Thu, Sep 16, 2021, 7:20 AM Josh Boyer  wrote:
> 
> > On Thu, Sep 16, 2021 at 10:10 AM Leon Fauster
> >  wrote:
> > >
> > > On 16.09.21 14:22, Josh Boyer wrote:
> > > > On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi  wrote:
> > > >>
> > > >> Just a heads up that ansible-core (the engine part of ansible) is now
> > in
> > > >> CentOS stream 9:
> > > >>
> > > >> https://gitlab.com/redhat/centos-stream/rpms/ansible-core
> > > >>
> > > >> Note that this is the engine, you will likely want to install
> > > >> collections for modules and roles, etc.
> > > >
> > > > For those that might not have followed how Ansible has been
> > > > refactored, take a look at
> > > > https://www.ansible.com/blog/ansible-3.0.0-qa
> > > >
> > > > ansible-core is the lowest level of the ansible stack and does not
> > > > include many of the modules and plugins that those using ansible
> > > > engine (ansible-2.9) might be used to.  As Kevin said, you will almost
> > > > certainly need additional modules/plugins not provided by
> > > > ansible-core.
> > >
> > >
> > > Out of curiosity
> > >
> > > Does CS9 provide additional (sub)packages to extend the functionality?
> >
> > Not generally.  ansible-core has been added to CS9 in support of
> > System Roles only.  This is analogous to how ansible is made available
> > in RHEL 8.  System Roles will include the modules/plugins it needs to
> > manage the various areas of the OS, but they are not general purpose
> > ansible packages.
> >
> > > Right now EPEL8 provide the the full stack based on ansible 2.9.
> > >
> > > Will EPEL9 provide such packages to provide additional modules/plugins?
> > >
> > > And more a ansible question: Does ansible3 provide a dependencies
> > > manager as consequence now?
> >
> > I'll leave these for Kevin or someone else to answer in terms of EPEL 9
> > plans.
> >
> > josh
> > ___
> > 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 on the list, report it:
> > https://pagure.io/fedora-infrastructure
> >

> ___
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure



signature.asc
Description: PGP signature
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2003640] Upgrade perl-Text-Template to 1.60

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2021-7286100d58 has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7286100d58


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2003640
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1858048] rt-5.0.2 is available

[bugzilla]

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



--- Comment #11 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
rt-5.0.2-1.fc32.src.rpm for rawhide failed
http://koji.fedoraproject.org/koji/taskinfo?taskID=75798911


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1858048
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1858048] rt-5.0.2 is available

[bugzilla]

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



--- Comment #10 from Upstream Release Monitoring 
 ---
Created attachment 1823610
  --> https://bugzilla.redhat.com/attachment.cgi?id=1823610=edit
[patch] Update to 5.0.2 (#1858048)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1858048
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1858048] rt-5.0.2 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|rt-5.0.1 is available   |rt-5.0.2 is available



--- Comment #9 from Upstream Release Monitoring 
 ---
Latest upstream release: 5.0.2
Current version/release in rawhide: 4.4.4-10.fc35
URL: http://bestpractical.com/request-tracker/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


Based on the information from anitya:
https://release-monitoring.org/project/7292/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1858048
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2002422] perl-IPC-Shareable-1.06 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-2021-c4c6e591cf has been submitted as an update to Fedora 35.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-c4c6e591cf


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2002422
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2005058] New: perl-PDF-API2-2.042 is available

[bugzilla]

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

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



Latest upstream release: 2.042
Current version/release in rawhide: 2.041-1.fc35
URL: http://search.cpan.org/dist/PDF-API2/

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


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


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


Based on the information from anitya:
https://release-monitoring.org/project/3202/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2005058
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Where has the kernel-doc package gone?

[Justin Forbes]

On Fri, Sep 3, 2021 at 4:04 PM Justin Forbes  wrote:
>
> On Thu, Sep 2, 2021 at 11:31 AM Nils K  wrote:
> >
> > I found the origin of this change to be the following commit: 
> > https://src.fedoraproject.org/rpms/kernel/c/b65f9ed036fca30c0684bfc6fe72d72a53e9867a?branch=f21
> >  (which is a revert of a revert to remove the kernel-doc subpackage).
> > The commit also suggest that the package might be a candidate for a 
> > separate SRPM which would maybe result in it not needing to be build 
> > everyday? Also if I understand you correctly I assume that some of the 
> > hacks to koji are not needed anymore.
> >
> > Due to this and given that RHEL includes it I think I will do as suggested 
> > and file a bug report.
> > Thanks for your responses.
>
>
> I suppose I can add it to the kernel-tools package since that only
> gets built once per RC for rawhide, and only as needed for stable
> Fedora.

So it turns out this just becomes more work to maintain in
kernel-tools, which wasn't really set up for this.  It is already
being maintained in the kernel.spec for ELN builds, so I have just
enabled it for Fedora as well. This will show up with the 5.14 rebases
as they happen.

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

Fedora-IoT-35-20210916.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/16 (x86_64), 1/15 (aarch64)

New failures (same test not failed in Fedora-IoT-35-20210915.0):

ID: 985689  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/985689
ID: 985695  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/985695

Old failures (same test failed in Fedora-IoT-35-20210915.0):

ID: 985703  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/985703

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-IoT-35-20210915.0):

ID: 985684  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/985684

Passed openQA tests: 13/16 (x86_64), 14/15 (aarch64)

New passes (same test not passed in Fedora-IoT-35-20210915.0):

ID: 985691  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/985691
ID: 985704  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/985704

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.35 to 0.09
Previous test data: https://openqa.fedoraproject.org/tests/983984#downloads
Current test data: https://openqa.fedoraproject.org/tests/985682#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.40 to 0.75
Previous test data: https://openqa.fedoraproject.org/tests/983999#downloads
Current test data: https://openqa.fedoraproject.org/tests/985697#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9

[Toshio Kuratomi]

I believe ansible-core includes a "dependency manager" depending on your
definition.  The ansible-galaxy command in ansible-core can install ansible
collections so that's you can install modules that you may need.

It is similar in scope to pip, rubygem, cargo, or any other of the language
package installers.

It does not resolve based on what modules/plugins are used in your
playbooks but it will resolve dependencies between collection dependencies
if needed (and those deps were properly listed).

I know that Nirik has plans to get newer ansible packages into epel which
provide an all-in-one experience by installing about 75 collections which
give you an experience similar what was included in ansible-2.9 but I'll
let him speak to how he wants to do that.

-Toshio

On Thu, Sep 16, 2021, 7:20 AM Josh Boyer  wrote:

> On Thu, Sep 16, 2021 at 10:10 AM Leon Fauster
>  wrote:
> >
> > On 16.09.21 14:22, Josh Boyer wrote:
> > > On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi  wrote:
> > >>
> > >> Just a heads up that ansible-core (the engine part of ansible) is now
> in
> > >> CentOS stream 9:
> > >>
> > >> https://gitlab.com/redhat/centos-stream/rpms/ansible-core
> > >>
> > >> Note that this is the engine, you will likely want to install
> > >> collections for modules and roles, etc.
> > >
> > > For those that might not have followed how Ansible has been
> > > refactored, take a look at
> > > https://www.ansible.com/blog/ansible-3.0.0-qa
> > >
> > > ansible-core is the lowest level of the ansible stack and does not
> > > include many of the modules and plugins that those using ansible
> > > engine (ansible-2.9) might be used to.  As Kevin said, you will almost
> > > certainly need additional modules/plugins not provided by
> > > ansible-core.
> >
> >
> > Out of curiosity
> >
> > Does CS9 provide additional (sub)packages to extend the functionality?
>
> Not generally.  ansible-core has been added to CS9 in support of
> System Roles only.  This is analogous to how ansible is made available
> in RHEL 8.  System Roles will include the modules/plugins it needs to
> manage the various areas of the OS, but they are not general purpose
> ansible packages.
>
> > Right now EPEL8 provide the the full stack based on ansible 2.9.
> >
> > Will EPEL9 provide such packages to provide additional modules/plugins?
> >
> > And more a ansible question: Does ansible3 provide a dependencies
> > manager as consequence now?
>
> I'll leave these for Kevin or someone else to answer in terms of EPEL 9
> plans.
>
> josh
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Thursday's FPC Meeting (2021-09-16 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-09-16 16:00 UTC in #fedora-meeting-1 on
irc.libera.chat.

 Local time information (via. uitime):

= Day: Thursday ==
2021-09-16 09:00 PDT  US/Pacific
2021-09-16 12:00 EDT  --> US/Eastern <--
2021-09-16 16:00 UTC  UTC   
2021-09-16 17:00 BST  Europe/London 
2021-09-16 18:00 CEST Europe/Berlin 
2021-09-16 18:00 CEST Europe/Paris  
2021-09-16 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2021-09-17 00:00 HKT  Asia/Hong_Kong
2021-09-17 00:00 +08  Asia/Singapore
2021-09-17 01:00 JST  Asia/Tokyo
2021-09-17 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

= Followup Issues =

#topic #886 Enable BRP for detecting RPATH 
.fpc 886
https://pagure.io/packaging-committee/issue/886

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #1058 How to handle %lang files in package owned directories? .fpc 1058
https://pagure.io/packaging-committee/issue/1058

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045

#topic #pr-1064 Update PIE section
https://pagure.io/packaging-committee/pull-request/1064

#topic #pr-1071 Overhaul the RPATH section of the guidelines.
https://pagure.io/packaging-committee/pull-request/1071

#topic #pr-1074 Require deleting unused bundled libraries during %prep
https://pagure.io/packaging-committee/pull-request/1074

#topic #pr-1077 Introduce %sysusers_create
https://pagure.io/packaging-committee/pull-request/1077

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
    that added topics may be deferred until the following meeting.









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

[EPEL-devel] Re: Pre-release EPEL

[Troy Dawson]

EPEL Next[1][2] is meant for machines running CentOS Stream.
We currently have epel8-next, and are working on getting epel9-next setup
so that maintainers can build on it.
Technically epel9-next will be a "Pre-Release" of epel9, but saying it is a
"pre-release" implies that it will go away.
epel9-next will not go away when epel9 is released, but will continue to be
for machines running CentOS Stream 9

Brought to you by the EPEL ELves

[1] - https://docs.fedoraproject.org/en-US/epel/#what_is_epel_next
[2] - https://docs.fedoraproject.org/en-US/epel/epel-about-next/

On Thu, Sep 16, 2021 at 7:30 AM Stephen Gallagher 
wrote:

> On Thu, Sep 16, 2021 at 10:11 AM Neal Gompa  wrote:
> >
> > On Thu, Sep 16, 2021 at 9:38 AM Thomas Stephen Lee 
> wrote:
> > >
> > > Hi,
> > >
> > > Thanks to people on the CentOS mailing list.
> > > We managed to get CentOS Stream 9 pre-release with updates working on
> a VM.
> > > Is there also a pre-release version of EPEL 9 we can use?
> > >
> >
> > Not just yet, I'm hoping that'll be soon...
>
> The EPELves are working as hard as they can, stay tuned!
> ___
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Pre-release EPEL

[Stephen Gallagher]

On Thu, Sep 16, 2021 at 10:11 AM Neal Gompa  wrote:
>
> On Thu, Sep 16, 2021 at 9:38 AM Thomas Stephen Lee  wrote:
> >
> > Hi,
> >
> > Thanks to people on the CentOS mailing list.
> > We managed to get CentOS Stream 9 pre-release with updates working on a VM.
> > Is there also a pre-release version of EPEL 9 we can use?
> >
>
> Not just yet, I'm hoping that'll be soon...

The EPELves are working as hard as they can, stay tuned!
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9

[Josh Boyer]

On Thu, Sep 16, 2021 at 10:10 AM Leon Fauster
 wrote:
>
> On 16.09.21 14:22, Josh Boyer wrote:
> > On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi  wrote:
> >>
> >> Just a heads up that ansible-core (the engine part of ansible) is now in
> >> CentOS stream 9:
> >>
> >> https://gitlab.com/redhat/centos-stream/rpms/ansible-core
> >>
> >> Note that this is the engine, you will likely want to install
> >> collections for modules and roles, etc.
> >
> > For those that might not have followed how Ansible has been
> > refactored, take a look at
> > https://www.ansible.com/blog/ansible-3.0.0-qa
> >
> > ansible-core is the lowest level of the ansible stack and does not
> > include many of the modules and plugins that those using ansible
> > engine (ansible-2.9) might be used to.  As Kevin said, you will almost
> > certainly need additional modules/plugins not provided by
> > ansible-core.
>
>
> Out of curiosity
>
> Does CS9 provide additional (sub)packages to extend the functionality?

Not generally.  ansible-core has been added to CS9 in support of
System Roles only.  This is analogous to how ansible is made available
in RHEL 8.  System Roles will include the modules/plugins it needs to
manage the various areas of the OS, but they are not general purpose
ansible packages.

> Right now EPEL8 provide the the full stack based on ansible 2.9.
>
> Will EPEL9 provide such packages to provide additional modules/plugins?
>
> And more a ansible question: Does ansible3 provide a dependencies
> manager as consequence now?

I'll leave these for Kevin or someone else to answer in terms of EPEL 9 plans.

josh
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Pre-release EPEL

[Neal Gompa]

On Thu, Sep 16, 2021 at 9:38 AM Thomas Stephen Lee  wrote:
>
> Hi,
>
> Thanks to people on the CentOS mailing list.
> We managed to get CentOS Stream 9 pre-release with updates working on a VM.
> Is there also a pre-release version of EPEL 9 we can use?
>

Not just yet, I'm hoping that'll be soon...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Packaging guidelines - clarification required - Users and Groups

[Michal Schorm]

Hello,
I seek a clarification on the "Users and Groups Guidelines" [1]
chapter of the "Fedora Packaging Guidelines" [2]

Please note I want such case to be clear to newcomers too.
While I am an experienced packager who has a fair idea how to navigate
in Fedora documentation, the same issue might be very confusing to the
packaging beginners among us.

--

During an attempt to update packages I maintain to match the Fedora
Packaging Guidelines, I encountered two different documents, from
which I cannot decide the correct one.
One is the (for me obviously) old [3] Guidelines page on the Wiki, but
it is NOT marked as obsolete, with the new guidelines ( I assume [1] )
linked, at the beginning of the document.

It is not easy to tell which of the documents is newer.
The "last edited" timestamp which is natural for Wiki is missing
entirely in the Docs.
The Docs has a value "Last build" in the footer, but that does not
provide information on the time the specific page was edited last.
My personal opinion is that Fedora has a fairly long ugly history of
documentation mess, so I'd deem it highly useful to NOT remove
lifebuoys (such as timestamps) from the pages, to allow Fedora
contributors to survive in the jungle of obsolete documentation. Git
blame on the page source is a lot of steps to be done to get such
information.

At first, it seems like part of the chapter "Soft static allocation"
with the code example from [4] is missing from the [5].
After careful investigation, it looks like a new system has been
adopted (".sysusers file" instead of "%pre scriptlet").
If that's true, the section "Values given to useradd and groupadd" [6]
feels more like a copy-paste error.
By examining the '%sysusers_create_compat' macro, I found out it does
the same thing as the code snippets in the other document [3].
The macro is brought in by 'systemd-rpm-macros' RPM. The name feels
deceiving - when talking about this very use case - as this very macro
itself is not related to systemd, but that's just one of the things
the package consists of. (so the name fits)

Then there is the package 'setup' [7], referenced by these Guidelines
documents. The package upstream is on Fedora Pagure [8].
And frankly, I have no idea what the package is supposed to do
regarding users, groups and ports listed in files 'uidgid' [9] and
'services' [10].
I am a maintainer of the packages 'community-mysql', 'mariadb' and more.
And I see that the 'mysql' name has a defined entry in both files and
neither is correct (up-to-date).
However I can't say I've ever encountered an issue with that, since I
create the 'mysql' user manually in the packages, as well as allowing
needed ports in the SELinux configuration.
So I would be grateful for an explanation of what those entries in the
'setup' package are used for.

Looking at the 'sysusers.generate-pre.sh' script [11], I can't tell
what the option "('m')" on line 67 is supposed to be for.
Actually, I'd use some documentation, since the code e.g. allows you
to set the shell only when you do not force a specific {UG}ID. I don't
understand this limitation and looking at [10] it is clear that a
_lot_ of system accounts use a different login shell than
"/sbin/nologin".



Summary:

Issues:
#1: Two Guideline documents with different content; neither marked as obsolete.
#2: Docs pages do not have a timestamp. Hard to tell which document is newer.
#3: The Guidelines differ and there seems to be a copy-paste error.

Questions:
#4: What is the purpose and usage of the 'setup' package?
#5: What are the guidelines around the 'setup' package? Does
everything that goes inside need FPC approval? Are the maintainers of
the referenced package responsible to keeping it up-to-date?
#6: Is there some documentation for the 'sysusers.generate-pre.sh' script?



[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
[2] https://docs.fedoraproject.org/en-US/packaging-guidelines/
[3] https://fedoraproject.org/wiki/Packaging:UsersAndGroups
[4] 
https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation
[5] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_soft_static_allocation
[6] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_values_given_to_useradd_and_groupadd
[7] https://src.fedoraproject.org/rpms/setup
[8] https://pagure.io/setup/tree/master
[9] https://pagure.io/setup/blob/master/f/services
[10] https://pagure.io/setup/blob/master/f/uidgid
[11] 
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/sysusers.generate-pre.sh
[12] 
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Fedora 35 compose report: 20210916.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-35-20210915.n.0
NEW: Fedora-35-20210916.n.0

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

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

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

= ADDED IMAGES =
Image: Cloud_Base tar-gz x86_64
Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-35-20210916.n.0.x86_64.tar.gz

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

[EPEL-devel] Pre-release EPEL

[Thomas Stephen Lee]

Hi,

Thanks to people on the CentOS mailing list.
We managed to get CentOS Stream 9 pre-release with updates working on a VM.
Is there also a pre-release version of EPEL 9 we can use?

Thanks

---
Lee
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to get list of retired packages?

[Miro Hrončok]

On 16. 09. 21 14:36, Miroslav Suchý wrote:

Hi.

What is the best way to get list of retired packages in F35? I can get list of 
all retired packages by scanning dist-git. But if I want it for one release of 
Fedora? And I do not want to do that manually; I rather want to script it.


Hello.

Do you want a list of retired components or a list of removed packages? Both 
are doable with repoquery (use the source repo for components):


$ comm -23 <(repoquery --releasever 34 --repo={fedora,updates}-source -a | 
pkgname | sort | uniq) <(repoquery --releasever 35 
--repo={fedora,updates}-source -a | pkgname | sort | uniq)


--
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-36-20210916.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 2/15 (aarch64), 1/16 (x86_64)

New failures (same test not failed in Fedora-IoT-36-20210915.0):

ID: 984971  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/984971
ID: 985388  Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_rebase
URL: https://openqa.fedoraproject.org/tests/985388

Old failures (same test failed in Fedora-IoT-36-20210915.0):

ID: 984975  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/984975

Soft failed openQA tests: 1/16 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-IoT-36-20210915.0):

ID: 984956  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/984956

Passed openQA tests: 14/16 (x86_64), 13/15 (aarch64)

New passes (same test not passed in Fedora-IoT-36-20210915.0):

ID: 984953  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/984953
ID: 984954  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/984954
ID: 984955  Test: x86_64 IoT-dvd_ostree-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/984955
ID: 984957  Test: x86_64 IoT-dvd_ostree-iso iot_greenboot
URL: https://openqa.fedoraproject.org/tests/984957
ID: 984958  Test: x86_64 IoT-dvd_ostree-iso base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/984958
ID: 984959  Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay
URL: https://openqa.fedoraproject.org/tests/984959
ID: 984961  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/984961
ID: 984962  Test: x86_64 IoT-dvd_ostree-iso base_selinux
URL: https://openqa.fedoraproject.org/tests/984962
ID: 984963  Test: x86_64 IoT-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/984963
ID: 984964  Test: x86_64 IoT-dvd_ostree-iso podman
URL: https://openqa.fedoraproject.org/tests/984964
ID: 984965  Test: x86_64 IoT-dvd_ostree-iso base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/984965
ID: 984966  Test: x86_64 IoT-dvd_ostree-iso base_system_logging
URL: https://openqa.fedoraproject.org/tests/984966
ID: 984967  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/984967
ID: 984968  Test: x86_64 IoT-dvd_ostree-iso podman_client
URL: https://openqa.fedoraproject.org/tests/984968
ID: 984969  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/984969
ID: 984970  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/984970
ID: 984972  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/984972
ID: 984973  Test: aarch64 IoT-dvd_ostree-iso base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/984973
ID: 984974  Test: aarch64 IoT-dvd_ostree-iso base_system_logging@uefi
URL: https://openqa.fedoraproject.org/tests/984974
ID: 984976  Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https://openqa.fedoraproject.org/tests/984976
ID: 984977  Test: aarch64 IoT-dvd_ostree-iso base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/984977
ID: 984978  Test: aarch64 IoT-dvd_ostree-iso base_service_manipulation@uefi
URL: https://openqa.fedoraproject.org/tests/984978
ID: 984979  Test: aarch64 IoT-dvd_ostree-iso podman@uefi
URL: https://openqa.fedoraproject.org/tests/984979
ID: 984980  Test: aarch64 IoT-dvd_ostree-iso iot_greenboot@uefi
URL: https://openqa.fedoraproject.org/tests/984980
ID: 984981  Test: aarch64 IoT-dvd_ostree-iso podman_client@uefi
URL: https://openqa.fedoraproject.org/tests/984981
ID: 984982  Test: aarch64 IoT-dvd_ostree-iso base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/984982
ID: 984983  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/984983
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20210916.n.0 compose check report

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
5 of 43 required tests failed, 5 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
MISSING: fedora.Cloud_Base-qcow2-qcow2.x86_64.64bit - compose.cloud_autocloud

Failed openQA tests: 20/207 (x86_64), 17/141 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20210915.n.0):

ID: 984633  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/984633
ID: 984634  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/984634
ID: 984653  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/984653
ID: 984666  Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/984666
ID: 984670  Test: x86_64 Cloud_Base-qcow2-qcow2 
base_package_install_remove@uefi
URL: https://openqa.fedoraproject.org/tests/984670
ID: 984705  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/984705
ID: 984714  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/984714
ID: 984715  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/984715
ID: 984720  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/984720
ID: 984721  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/984721
ID: 984728  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/984728
ID: 984730  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/984730
ID: 984731  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/984731
ID: 984754  Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/984754
ID: 984832  Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/984832
ID: 984837  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/984837

Old failures (same test failed in Fedora-Rawhide-20210915.n.0):

ID: 984578  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/984578
ID: 984584  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/984584
ID: 984585  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/984585
ID: 984593  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/984593
ID: 984596  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/984596
ID: 984600  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/984600
ID: 984601  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/984601
ID: 984612  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/984612
ID: 984745  Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/984745
ID: 984800  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/984800
ID: 984810  Test: x86_64 universal memtest
URL: https://openqa.fedoraproject.org/tests/984810
ID: 984811  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/984811
ID: 984817  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/984817
ID: 984833  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/984833
ID: 984848  Test: aarch64 universal install_repository_http_variation@uefi
URL: https://openqa.fedoraproject.org/tests/984848
ID: 984849  Test: aarch64 universal upgrade_minimal_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/984849
ID: 984859  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/984859
ID: 984860  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/984860
ID: 984865  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/984865
ID: 984869  Test: aarch64 universal 

Self Introduction: Jan Baudisch

[Jan Baudisch]

Hi,

I am a computer science student from Germany and have used Fedora for
at least 2 years by now.

Using COPR I gained some experience in buidling packages but recently I
wanted to try building packages conforming to the guidelines and
getting them into Fedora. My interest is mostly in Rust and that is why
I would like to contribute Rust packages. I already got started here:
https://copr.fedorainfracloud.org/coprs/janbaudisch/rust/packages

For now my main interest would be to get the Rocket framework packaged,
as many projects rely on it and on the way I discovered some key Rust
crates not packaged yet.

I feel like some of them are ready for submission and will file the
first review requests soon.

Looking forward to working on this!

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

Re: How to get list of retired packages?

[Pierre-Yves Chibon]

On Thu, Sep 16, 2021 at 02:36:58PM +0200, Miroslav Suchý wrote:
> Hi.
> 
> What is the best way to get list of retired packages in F35? I can get list
> of all retired packages by scanning dist-git. But if I want it for one
> release of Fedora? And I do not want to do that manually; I rather want to
> script it.
> 
PDC would be your source of truth for this info. You'll need to look at the
"active" state of the package/branch.


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

Re: How to get list of retired packages?

[Neal Gompa]

On Thu, Sep 16, 2021 at 8:37 AM Miroslav Suchý  wrote:
>
> Hi.
>
> What is the best way to get list of retired packages in F35? I can get list 
> of all retired packages by scanning
> dist-git. But if I want it for one release of Fedora? And I do not want to do 
> that manually; I rather want to script it.
>

You can poke Pagure via the API for the presence of the dead.package
file in the "f35" branch, as you're probably aware. But PDC would have
the collection of active source packages for a release, though I'm not
sure you can get that from its API. If you can, then you can derive
the retired package set by removing the intersection of the total set
of packages from Pagure and the set of active packages in PDC.




--
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

How to get list of retired packages?

[Miroslav Suchý]

Hi.

What is the best way to get list of retired packages in F35? I can get list of all retired packages by scanning 
dist-git. But if I want it for one release of Fedora? And I do not want to do that manually; I rather want to script it.


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

Re: Fedora rawhide compose report: 20210916.n.0 changes

[Luna Jernberg]

g-i-s is still broken in the Workstation iso for Rawhide today btw just
fyi, crashing after install in a Virtualbox VM for me

On Thu, Sep 16, 2021 at 2:20 PM Kalev Lember  wrote:

> On Thu, Sep 16, 2021 at 2:14 PM Fabio Valentini 
> wrote:
>
>> On Thu, Sep 16, 2021 at 1:09 PM Fedora Rawhide Report
>>  wrote:
>> > = ADDED PACKAGES =
>> > Package: atkmm2.36-2.36.1-1.fc36
>> > Summary: C++ interface for the ATK library
>> > RPMs:atkmm2.36 atkmm2.36-devel atkmm2.36-doc
>> > Size:1.35 MiB
>>
>> (...)
>>
>> > Package: glibmm2.68-2.68.1-1.fc36
>> > Summary: C++ interface for the GLib library
>> > RPMs:glibmm2.68 glibmm2.68-devel glibmm2.68-doc
>> > Size:12.65 MiB
>> >
>> > Package: gtkmm4.0-4.4.0-1.fc36
>> > Summary: C++ interface for the GTK+ library
>> > RPMs:gtkmm4.0 gtkmm4.0-devel gtkmm4.0-doc
>> > Size:17.64 MiB
>> >
>> > Package: pangomm2.48-2.48.1-1.fc36
>> > Summary: C++ interface for Pango
>> > RPMs:pangomm2.48 pangomm2.48-devel pangomm2.48-doc
>> > Size:1.26 MiB
>>
>> Is there a reason why these compat packages are done "the wrong way
>> round"?
>> They were requested with exceptions to the review process, but that
>> exception only applies to requesting versioned compat packages for the
>> *old* version, not the other way round ...
>>
>
> Sure, there's a good reason! I wanted to keep the same pattern as gtk has,
> so that there's gtk3 and matching gtkmm3.0, and gtk4 and matching gtkmm4.0.
>
> They are all long-lived parallel installable packages and most stuff is
> going to be using the "old" gtkmm3.0 still for a number of years to come.
>
> Doing it this way also makes it much easier to add the new packages to F34
> where I don't want to be undertaking large package renaming.
>
> --
> Kalev
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: is possible rollback Epoch bump on epel ?

[Neal Gompa]

On Thu, Sep 16, 2021 at 7:46 AM Miroslav Suchý  wrote:
>
> Dne 16. 09. 21 v 13:23 Sérgio Basto napsal(a):
> > the question is, can I remove Epoch tag ? or should I put Epoch in
> > every branch, i.e epel 8 ?
> >
> > Thank you .
>
> Once you introduce the epoch, you have to keep it. And only increment it.
>
> There is no way to get it rid of it. At least no way I can recommend :)
>

Epochs can *only* be reset on system upgrades, because you're either
reinstalling or using the distro-sync upgrade method (which does not
necessarily care about EVRs).

Neither case happens within a particular EPEL branch. So you're stuck
with it until the next RHEL major version release.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: ansible-core-2.11.x in CentOS stream 9

[Josh Boyer]

On Wed, Sep 15, 2021 at 3:48 PM Kevin Fenzi  wrote:
>
> Just a heads up that ansible-core (the engine part of ansible) is now in
> CentOS stream 9:
>
> https://gitlab.com/redhat/centos-stream/rpms/ansible-core
>
> Note that this is the engine, you will likely want to install
> collections for modules and roles, etc.

For those that might not have followed how Ansible has been
refactored, take a look at
https://www.ansible.com/blog/ansible-3.0.0-qa

ansible-core is the lowest level of the ansible stack and does not
include many of the modules and plugins that those using ansible
engine (ansible-2.9) might be used to.  As Kevin said, you will almost
certainly need additional modules/plugins not provided by
ansible-core.

josh
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora rawhide compose report: 20210916.n.0 changes

[Kalev Lember]

On Thu, Sep 16, 2021 at 2:14 PM Fabio Valentini 
wrote:

> On Thu, Sep 16, 2021 at 1:09 PM Fedora Rawhide Report
>  wrote:
> > = ADDED PACKAGES =
> > Package: atkmm2.36-2.36.1-1.fc36
> > Summary: C++ interface for the ATK library
> > RPMs:atkmm2.36 atkmm2.36-devel atkmm2.36-doc
> > Size:1.35 MiB
>
> (...)
>
> > Package: glibmm2.68-2.68.1-1.fc36
> > Summary: C++ interface for the GLib library
> > RPMs:glibmm2.68 glibmm2.68-devel glibmm2.68-doc
> > Size:12.65 MiB
> >
> > Package: gtkmm4.0-4.4.0-1.fc36
> > Summary: C++ interface for the GTK+ library
> > RPMs:gtkmm4.0 gtkmm4.0-devel gtkmm4.0-doc
> > Size:17.64 MiB
> >
> > Package: pangomm2.48-2.48.1-1.fc36
> > Summary: C++ interface for Pango
> > RPMs:pangomm2.48 pangomm2.48-devel pangomm2.48-doc
> > Size:1.26 MiB
>
> Is there a reason why these compat packages are done "the wrong way round"?
> They were requested with exceptions to the review process, but that
> exception only applies to requesting versioned compat packages for the
> *old* version, not the other way round ...
>

Sure, there's a good reason! I wanted to keep the same pattern as gtk has,
so that there's gtk3 and matching gtkmm3.0, and gtk4 and matching gtkmm4.0.

They are all long-lived parallel installable packages and most stuff is
going to be using the "old" gtkmm3.0 still for a number of years to come.

Doing it this way also makes it much easier to add the new packages to F34
where I don't want to be undertaking large package renaming.

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

Re: Fedora rawhide compose report: 20210916.n.0 changes

[Fabio Valentini]

On Thu, Sep 16, 2021 at 1:09 PM Fedora Rawhide Report
 wrote:
> = ADDED PACKAGES =
> Package: atkmm2.36-2.36.1-1.fc36
> Summary: C++ interface for the ATK library
> RPMs:atkmm2.36 atkmm2.36-devel atkmm2.36-doc
> Size:1.35 MiB

(...)

> Package: glibmm2.68-2.68.1-1.fc36
> Summary: C++ interface for the GLib library
> RPMs:glibmm2.68 glibmm2.68-devel glibmm2.68-doc
> Size:12.65 MiB
>
> Package: gtkmm4.0-4.4.0-1.fc36
> Summary: C++ interface for the GTK+ library
> RPMs:gtkmm4.0 gtkmm4.0-devel gtkmm4.0-doc
> Size:17.64 MiB
>
> Package: pangomm2.48-2.48.1-1.fc36
> Summary: C++ interface for Pango
> RPMs:pangomm2.48 pangomm2.48-devel pangomm2.48-doc
> Size:1.26 MiB

Is there a reason why these compat packages are done "the wrong way round"?
They were requested with exceptions to the review process, but that
exception only applies to requesting versioned compat packages for the
*old* version, not the other way round ...

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: is possible rollback Epoch bump on epel ?

[Miroslav Suchý]

Dne 16. 09. 21 v 13:23 Sérgio Basto napsal(a):

the question is, can I remove Epoch tag ? or should I put Epoch in
every branch, i.e epel 8 ?

Thank you .


Once you introduce the epoch, you have to keep it. And only increment it.

There is no way to get it rid of it. At least no way I can recommend :)

Miroslav
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] is possible rollback Epoch bump on epel ?

[Sérgio Basto]

Hi, 
In practice, after bug [1] I decided rollback update on epel 7 with one
epoch bump [2]. Now after one year and half and after testing, we know
if we removing one line it works, so I want rollback the rollback and
update debmirror on epel7 to support Ubuntu 20.04 ... 

the question is, can I remove Epoch tag ? or should I put Epoch in
every branch, i.e epel 8 ? 

Thank you . 


[1] 
https://bugzilla.redhat.com/show_bug.cgi?id=1801338


[2] 
https://src.fedoraproject.org/rpms/debmirror/commits/epel7
-- 
Sérgio M. B.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20210916.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210915.n.0
NEW: Fedora-Rawhide-20210916.n.0

= SUMMARY =
Added images:0
Dropped images:  4
Added packages:  6
Dropped packages:0
Upgraded packages:   118
Downgraded packages: 0

Size of added packages:  41.59 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.78 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Scientific vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210915.n.0.x86_64.vagrant-virtualbox.box
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20210915.n.0.iso
Image: Scientific vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Scientific-Vagrant-Rawhide-20210915.n.0.x86_64.vagrant-libvirt.box
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20210915.n.0.iso

= ADDED PACKAGES =
Package: atkmm2.36-2.36.1-1.fc36
Summary: C++ interface for the ATK library
RPMs:atkmm2.36 atkmm2.36-devel atkmm2.36-doc
Size:1.35 MiB

Package: fedora-jam-backgrounds-2.0.0-4.fc36
Summary: Fedora Jam desktop backgrounds
RPMs:fedora-jam-backgrounds fedora-jam-backgrounds-gnome 
fedora-jam-backgrounds-kde fedora-jam-backgrounds-single 
fedora-jam-backgrounds-xfce
Size:8.08 MiB

Package: fedora-jam-kde-theme-3.0.6-3.fc36
Summary: Fedora Jam KDE Theme and Configs
RPMs:fedora-jam-kde-theme
Size:625.21 KiB

Package: glibmm2.68-2.68.1-1.fc36
Summary: C++ interface for the GLib library
RPMs:glibmm2.68 glibmm2.68-devel glibmm2.68-doc
Size:12.65 MiB

Package: gtkmm4.0-4.4.0-1.fc36
Summary: C++ interface for the GTK+ library
RPMs:gtkmm4.0 gtkmm4.0-devel gtkmm4.0-doc
Size:17.64 MiB

Package: pangomm2.48-2.48.1-1.fc36
Summary: C++ interface for Pango
RPMs:pangomm2.48 pangomm2.48-devel pangomm2.48-doc
Size:1.26 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  TeXmacs-2.1-1.fc36
Old package:  TeXmacs-1.99.13-6.fc34
Summary:  Structured WYSIWYG scientific text editor
RPMs: TeXmacs TeXmacs-devel texmacs-fedora-fonts
Size: 264.67 MiB
Size change:  451.90 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
1.99.18-2
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Thu Sep 16 2021 Orion Poplawski  - 2.1-1
  - Update to 2.1


Package:  annobin-10.05-1.fc36
Old package:  annobin-10.02-1.fc36
Summary:  Annotate and examine compiled binary files
RPMs: annobin-annocheck annobin-docs annobin-plugin-clang 
annobin-plugin-gcc annobin-plugin-llvm
Size: 5.10 MiB
Size change:  10.60 KiB
Changelog:
  * Wed Sep 15 2021 Nick Clifton   - 10.03-1
  - Annocheck: Do not set CFLAGS/LDFLAGS when building.  Take from environment 
instead.

  * Wed Sep 15 2021 Nick Clifton   - 10.04-1
  - Annocheck: With gaps at the start/end of the .text section, check for 
special symbols before displaying a MAYB result.

  * Wed Sep 15 2021 Nick Clifton   - 10.05-1
  - Annocheck: Do not insist on the DT_AARCH64_PAC_PLT flag being present in 
AArch64 binaries.


Package:  breeze-icon-theme-5.86.0-1.fc36
Old package:  breeze-icon-theme-5.85.0-1.fc36
Summary:  Breeze icon theme
RPMs: breeze-icon-theme breeze-icon-theme-rcc
Size: 8.76 MiB
Size change:  10.51 KiB
Changelog:
  * Tue Sep 14 2021 Marc Deop  - 5.86.0-1
  - 5.86.0


Package:  cadvisor-0.40.0-2.fc36
Old package:  cadvisor-0.38.6-2.fc34
Summary:  Analyzes resource usage and performance characteristics of 
running containers
RPMs: cadvisor golang-github-google-cadvisor-devel
Size: 40.81 MiB
Size change:  -581.56 KiB
Changelog:
  * Wed Jul 21 2021 Fedora Release Engineering  - 
0.38.6-3
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

  * Wed Sep 15 2021 Robert-Andr?? Mauchin  0.40.0-1
  - Update to 0.40.0 Close: rhbz#1915882   Close: rhbz#1987396

  * Wed Sep 15 2021 Robert-Andr?? Mauchin  0.40.0-2
  - Disable tests for 32 bits arches


Package:  catatonit-0.1.6-1.fc36
Old package:  catatonit-0.1.5-6.fc36
Summary:  A signal-forwarding process manager for containers
RPMs: catatonit
Size: 1.40 MiB
Size change:  10.00 KiB
Changelog:
  * Thu Sep 16 2021 RH Container Bot  - 
0.1.6-1
  - autobuilt v0.1.6


Package:  cbmc-5.38.0-1.fc36
Old package:  cbmc-5.37.0-1.fc36
Summary:  Bounded Model Checker for ANSI-C and C++ programs
RPMs: cbmc cbmc-doc cbmc-utils
Size: 200.83 MiB
Size change:  440.45 KiB
Changelog:
  * Wed Sep 15 2021 Vincent Mihalkovic  - 5.38.0-1
  - New upstream release of cbmc and also cbmc-utils


Package:  certmonger-0.79.14-4.fc36
Old package:  certmonger-0.79.14-2.fc36
Summary:  Certificate status monitor and PKI enrollment client
RPMs: certmonger
Size: 2.87

Re: RH Bugzilla extrem slow loading at enter_bug.cgi for Fedora

[Marius Schwarz]

Am 15.09.21 um 14:38 schrieb Miro Hrončok:

On 10. 09. 21 18:50, Marius Schwarz wrote:

Hi,

since a few days, loading the enter_bug.cgi for "Product=Fedora" on 
RH BZ takes very long.

It's quite possible, that it's happening for any other product too ;)

It's over a minute ATM.


I have the same problem. have you contacted the RH bugzilla admins or 
should I do that?



Update:

Under first impression, the amount of components in Fedora makes it 
slow, as other BZ "Products" are loading as expected.


For anyone interessted, it's now a bug:

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

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

Re: Claiming ownership for gtg and pyhton-liblarch

[Miguel R.]

I have already  submited "pyhton-liblarch" for review, I didn't 
submited "gtg" yet because to be able to run "gtg" and check if 
everything is ok, I need first to re-add "liblarch", as it is a 
dependency of "gtg".


This is the review request link: 



FAS: miguel7ra

On Wed, Sep 15 2021 at 02:35:16 PM -0700, Kevin Fenzi  
wrote:

On Sun, Sep 12, 2021 at 10:37:17PM -0300, Miguel R. Araújo wrote:
 I still need someone to sponsor me into the packager group to be 
able to
 maintain these packages. But if I can find someone, I would be glad 
if you

 would help me as a co-maintainer.
 FAS: miguel7ra


Hey Miguel.

Since these packages were retired so long ago, they need to be
re-reviewed before they can be re-added.

Can you submit reviews of the updated versions of them?

If I can find the time I'd be happy to then review and sponsor you.
If not, hopefully someone else can. ;)

kevin
--


 On Mon, Sep 13 2021 at 01:11:36 AM -, Thomas Vandal
 mailto:thomasvan...@hotmail.com>> wrote:
 > Hi Miguel,
 >
 > I'd be happy help as a co-maintainer for these two packages if 
you are
 > looking for one. I am new to packaging software for Fedora, but 
GTG is
 > one of the applications I use and would like to see in the repos 
as
 > well. I plan to look more into how to package python software 
later this

 > week.
 >
 > Best,
 >
 > Thomas Vandal
 >
 > >  Hello.
 > >
 > >  The gtg package was retired 3 years ago because of inactive
 > > upstream,
 > >  but it's been active for a while so I'd like to maintain it. 
To do

 > >  this, I need to become the owner of the "gtg" package and the
 > >  "python-liblarch" package, which is a dependency of "gtg" and 
was

 > > also
 > >
 > >  retired because of inactive upstream, but has returned to 
activity

 > >  along with gtg.
 > >
 > >  Thanks for your attention.
 > ___
 > devel mailing list -- devel@lists.fedoraproject.org 


 > <>
 > To unsubscribe send an email to 
devel-le...@lists.fedoraproject.org 


 > <>
 > Fedora Code of Conduct:
 > <>
 > List Guidelines:
 > <>
 > List Archives: 
<>

 > Do not reply to spam on the list, report it:
 > <>




 ___
 devel mailing list -- devel@lists.fedoraproject.org 

 To unsubscribe send an email to devel-le...@lists.fedoraproject.org 

 Fedora Code of Conduct: 

 List Guidelines: 

 List Archives: 

 Do not reply to spam on the list, report it: 



___
devel mailing list -- devel@lists.fedoraproject.org 

To unsubscribe send an email to devel-le...@lists.fedoraproject.org 

Fedora Code of Conduct: 

List Guidelines: 

List Archives: 

Do not reply to spam on the list, report it: 



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

Fedora-Cloud-34-20210916.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20210915.0):

ID: 984533  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/984533
ID: 984543  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/984543

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36

[Zbigniew Jędrzejewski-Szmek]

On Thu, Sep 16, 2021 at 08:20:06AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Sep 16, 2021 at 08:13:08AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Sep 15, 2021 at 07:53:46PM +0200, Sahana Prasad wrote:
> > > On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík  wrote:
> > > 
> > > > Hi Sahana,
> > > >
> > > > it would be nice, if changelog entry contained bug id we could use to
> > > > watch the progress. Or any other link to some tracker. bind package has 
> > > > a
> > > > new release, I am preparing update for it, but I am not sure where 
> > > > should I
> > > > watch for a progress. Even build of openssl itself does not reference 
> > > > any
> > > > bug. Is there any better tracker than bug #1825937, which I can monitor 
> > > > for
> > > > progress? Is the koji build the best way to check readiness? Does exist 
> > > > any
> > > > variant of RHEL9 bug #1958021
> > > >  for Fedora 
> > > > Rawhide?
> > > >
> > > > Is there any expected timeline, how long it might take to merge the
> > > > side-tag?
> > > >
> > > 
> > > Hi Petr,
> > > 
> > > I have merged the side-tag [1].
> > > I would however need karma for it to get to stable.
> > > 
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
> > > 
> > > I will send a list of the failed packages shortly.
> > 
> > systemd was built into the side-tag yesterday [1],
> > but doesn't appear in the update…
> > 
> > [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1832196
> 
> Oh, I see it finished building after you merged the tag. Dunno,
> maybe the update should be updated?
> 
> --
> 
> Another issue: the update has 1006 "automated tests", out of which
> 1001 fail! I think is very wrong with "automated tests" is the
> out-of-the-box success rate is below 0.005%.
> 
> Error: 
>  Problem: conflicting requests
>   - nothing provides libcrypto.so.3()(64bit) needed by 
> zola-0.12.2-8.fc36.x86_64
>   - nothing provides libcrypto.so.3(OPENSSL_3.0.0)(64bit) needed by 
> zola-0.12.2-8.fc36.x86_64
>   - nothing provides libssl.so.3()(64bit) needed by zola-0.12.2-8.fc36.x86_64
>   - nothing provides libssl.so.3(OPENSSL_3.0.0)(64bit) needed by 
> zola-0.12.2-8.fc36.x86_64
> (try to add '--skip-broken' to skip uninstallable packages)
> Installation of zola-0:0.12.2-8.fc36.x86_64 failed.
> 
> So... is the test ignoring the fact that the package is part of
> an update and trying to install rpms individually?

Another one 
(https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/42395/testReport/(root)/tests/_annocheck/)

"""
Error Message
Test "/annocheck" failed.
Find out more about this test in the documentation: 
https://github.com/rpminspect/rpminspect#rpminspect
Found a bug? Please open an issue in the issue tracker: 
https://pagure.io/fedora-ci/general/issues
"""

How on earth are we supposed to figure out what annocheck doesn't like?
There's 185328 bytes of "Standard Output" that follows…

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36

[Zbigniew Jędrzejewski-Szmek]

On Thu, Sep 16, 2021 at 08:13:08AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Sep 15, 2021 at 07:53:46PM +0200, Sahana Prasad wrote:
> > On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík  wrote:
> > 
> > > Hi Sahana,
> > >
> > > it would be nice, if changelog entry contained bug id we could use to
> > > watch the progress. Or any other link to some tracker. bind package has a
> > > new release, I am preparing update for it, but I am not sure where should 
> > > I
> > > watch for a progress. Even build of openssl itself does not reference any
> > > bug. Is there any better tracker than bug #1825937, which I can monitor 
> > > for
> > > progress? Is the koji build the best way to check readiness? Does exist 
> > > any
> > > variant of RHEL9 bug #1958021
> > >  for Fedora Rawhide?
> > >
> > > Is there any expected timeline, how long it might take to merge the
> > > side-tag?
> > >
> > 
> > Hi Petr,
> > 
> > I have merged the side-tag [1].
> > I would however need karma for it to get to stable.
> > 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
> > 
> > I will send a list of the failed packages shortly.
> 
> systemd was built into the side-tag yesterday [1],
> but doesn't appear in the update…
> 
> [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1832196

Oh, I see it finished building after you merged the tag. Dunno,
maybe the update should be updated?

--

Another issue: the update has 1006 "automated tests", out of which
1001 fail! I think is very wrong with "automated tests" is the
out-of-the-box success rate is below 0.005%.

Error: 
 Problem: conflicting requests
  - nothing provides libcrypto.so.3()(64bit) needed by zola-0.12.2-8.fc36.x86_64
  - nothing provides libcrypto.so.3(OPENSSL_3.0.0)(64bit) needed by 
zola-0.12.2-8.fc36.x86_64
  - nothing provides libssl.so.3()(64bit) needed by zola-0.12.2-8.fc36.x86_64
  - nothing provides libssl.so.3(OPENSSL_3.0.0)(64bit) needed by 
zola-0.12.2-8.fc36.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
Installation of zola-0:0.12.2-8.fc36.x86_64 failed.

So... is the test ignoring the fact that the package is part of
an update and trying to install rpms individually?

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36

[Zbigniew Jędrzejewski-Szmek]

On Wed, Sep 15, 2021 at 07:53:46PM +0200, Sahana Prasad wrote:
> On Wed, Sep 15, 2021 at 12:57 PM Petr Menšík  wrote:
> 
> > Hi Sahana,
> >
> > it would be nice, if changelog entry contained bug id we could use to
> > watch the progress. Or any other link to some tracker. bind package has a
> > new release, I am preparing update for it, but I am not sure where should I
> > watch for a progress. Even build of openssl itself does not reference any
> > bug. Is there any better tracker than bug #1825937, which I can monitor for
> > progress? Is the koji build the best way to check readiness? Does exist any
> > variant of RHEL9 bug #1958021
> >  for Fedora Rawhide?
> >
> > Is there any expected timeline, how long it might take to merge the
> > side-tag?
> >
> 
> Hi Petr,
> 
> I have merged the side-tag [1].
> I would however need karma for it to get to stable.
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee8c904f46
> 
> I will send a list of the failed packages shortly.

systemd was built into the side-tag yesterday [1],
but doesn't appear in the update…

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1832196

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 1892743] Upgrade perl-Type-Tiny to 1.012004

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
   Fixed In Version||perl-Type-Tiny-1.012004-1.f
   ||c36
   ||perl-Type-Tiny-1.012004-1.f
   ||c35
   ||perl-Type-Tiny-1.012004-1.f
   ||c34
Last Closed||2021-09-16 08:09:29



--- Comment #5 from Jitka Plesnikova  ---
perl-Type-Tiny-1.012004-1.fc36, perl-Type-Tiny-1.012004-1.fc35,
perl-Type-Tiny-1.012004-1.fc34 built by corsepiu


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1892743
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-33-20210916.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (aarch64)

New failures (same test not failed in Fedora-Cloud-33-20210915.0):

ID: 984525  Test: aarch64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/984525

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-33-20210915.0):

ID: 984517  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/984517
ID: 984527  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/984527

Passed openQA tests: 7/8 (x86_64), 6/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36

[Neal Gompa]

On Wed, Sep 15, 2021 at 10:26 PM Gary Buhrmaster
 wrote:
>
> On Wed, Sep 15, 2021 at 9:40 PM Fabio Valentini  wrote:
>
> > Thanks, that did the trick.
> > But of course somebody built stuff during the side-tag window and now
> > it can't be pushed. *le big sigh*
>
> This seems to happen every time there is a
> large(ish) side-tag.  I do wish that (probably
> using a server side git push hook) there was
> a `fedpkg lock` command that would block
> accidental pushes for the appropriate branch
> due to various missed emails, or automated
> activities (with the corresponding `fedpkg
> unlock` of course).  Ah well, one can dream.

It's *possible*. Pagure Dist-Git[0] dynamically generates the ACLs
from PDC, so if someone wanted to work on PDC to offer an API that
could be used to temporarily close a branch until a certain date
passed or until a side-tag was merged (obviously by listening to
fedora messaging queue for it), then fedpkg could be extended to offer
"fedpkg lock" to lock rawhide branches temporarily accordingly.

The problem is that PDC has been a dead project since early 2018[1]
(just shortly after Pagure went into production at the end of 2017).
So despite being made extremely critical to our infrastructure, unless
someone has the chops to extend the codebase themselves, the other
pieces will never gain the necessary capabilities.

[0]: https://pagure.io/pagure-dist-git
[1]: 
https://github.com/product-definition-center/product-definition-center/commits/master



-- 
真実はいつも一つ！/ 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 on the list, report it: 
https://pagure.io/fedora-infrastructure