Re: SONAME BUMP HEADS-UP: ntfs-3g update for fixing multiple CVEs

[Richard W.M. Jones]

On Tue, Aug 31, 2021 at 11:20:30PM +0100, Richard W.M. Jones wrote:
> On Tue, Aug 31, 2021 at 05:25:47PM -0400, Neal Gompa wrote:
> > * libguestfs
> > * ntfs-3g-system-compression
> 
> I will do these two packages.

Dammit, side tags ...
Here are the builds:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1826420
ntfs-3g-system-compression-1.0-7.fc36

https://koji.fedoraproject.org/koji/buildinfo?buildID=1826421
ntfs-3g-system-compression-1.0-7.fc35 (f35-build-side-45239)

https://koji.fedoraproject.org/koji/buildinfo?buildID=1826422
ntfs-3g-system-compression-1.0-7.fc34 (f34-build-side-45241)

https://koji.fedoraproject.org/koji/buildinfo?buildID=1826428
libguestfs-1.45.7-2.fc36

https://koji.fedoraproject.org/koji/taskinfo?taskID=74883815
libguestfs-1.45.7-2.fc35 (f35-build-side-45239)

https://koji.fedoraproject.org/koji/taskinfo?taskID=74883788
libguestfs-1.45.7-2.fc34 (f34-build-side-45241)

If any of them fail I'll take a look tomorrow morning.

Also nbdkit in Rawhide at least needs to be rebuilt but I'll deal with
that one too.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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: SONAME BUMP HEADS-UP: ntfs-3g update for fixing multiple CVEs

[Richard W.M. Jones]

On Tue, Aug 31, 2021 at 11:20:30PM +0100, Richard W.M. Jones wrote:
> On Tue, Aug 31, 2021 at 05:25:47PM -0400, Neal Gompa wrote:
> > * libguestfs
> > * ntfs-3g-system-compression
> 
> I will do these two packages.

Dammit, side tags ...
Here are the builds:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1826420
ntfs-3g-system-compression-1.0-7.fc36

https://koji.fedoraproject.org/koji/buildinfo?buildID=1826421
ntfs-3g-system-compression-1.0-7.fc35 (f35-build-side-45239)

https://koji.fedoraproject.org/koji/buildinfo?buildID=1826422
ntfs-3g-system-compression-1.0-7.fc34 (f34-build-side-45241)

https://koji.fedoraproject.org/koji/buildinfo?buildID=1826428
libguestfs-1.45.7-2.fc36

https://koji.fedoraproject.org/koji/taskinfo?taskID=74883815
libguestfs-1.45.7-2.fc35 (f35-build-side-45239)

https://koji.fedoraproject.org/koji/taskinfo?taskID=74883788
libguestfs-1.45.7-2.fc34 (f34-build-side-45241)

If any of them fail I'll take a look tomorrow morning.

Also nbdkit in Rawhide at least needs to be rebuilt but I'll deal with
that one too.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-37aab93b64   
libss7-2.0.1-1.el7
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-bf4abce815   
libopenmpt-0.5.11-1.el7


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

bgpq4-1.4-1.el7
cscppc-2.0.0-1.el7
csdiff-2.2.0-1.el7
csmock-2.9.0-1.el7
cswrap-2.0.1-1.el7
gfal2-util-1.6.0-1.el7
netcat-1.218-1.el7
uhubctl-2.4.0-2.el7

Details about builds:



 bgpq4-1.4-1.el7 (FEDORA-EPEL-2021-1d75dce5c6)
 Automate BGP filter generation based on routing database information

Update Information:

bgpq 1.4 - Fix BIRD aspath output   bgpq 1.3 - Refactor:
replace two-dimensional array for ASN storage with Red-Black tree   - Reduced
memory usage

ChangeLog:

* Fri Aug 20 2021 Robert Scheck  1.4-1
- Upgrade to 1.4 (#1996194)

References:

  [ 1 ] Bug #1996194 - bgpq4-1.4 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1996194




 cscppc-2.0.0-1.el7 (FEDORA-EPEL-2021-8e312a58c0)
 A compiler wrapper that runs cppcheck in background

Update Information:

- update to the latest upstream release

ChangeLog:

* Tue Aug 31 2021 Kamil Dudka  2.0.0-1
- update to latest upstream release




 csdiff-2.2.0-1.el7 (FEDORA-EPEL-2021-8e312a58c0)
 Non-interactive tools for processing code scan results in plain-text

Update Information:

- update to the latest upstream release

ChangeLog:

* Tue Aug 31 2021 Kamil Dudka  2.2.0-1
- update to latest upstream release




 csmock-2.9.0-1.el7 (FEDORA-EPEL-2021-8e312a58c0)
 A mock wrapper for Static Analysis tools

Update Information:

- update to the latest upstream release

ChangeLog:

* Tue Aug 31 2021 Kamil Dudka  2.9.0-1
- update to latest upstream release




 cswrap-2.0.1-1.el7 (FEDORA-EPEL-2021-8e312a58c0)
 Generic compiler wrapper

Update Information:

- update to the latest upstream release

ChangeLog:

* Tue Aug 31 2021 Kamil Dudka  2.0.1-1
- update to latest upstream




 gfal2-util-1.6.0-1.el7 (FEDORA-EPEL-2021-0043f07d5f)
 GFAL2 utility tools

Update Information:

New upstream release

ChangeLog:

* Tue Aug 31 2021 Michal Simon  - 1.6.0-1
- New upstream release




 netcat-1.218-1.el7 (FEDORA-EPEL-2021-281080c407)
 OpenBSD netcat to read and write data across connections using TCP or UDP

Update Information:

OpenBSD netcat 1.218 - One of the examples needs an `-N`
(and explanation)

ChangeLog:

* Mon Aug 30 2021 Robert Scheck  1.218-1
- Upgrade to 1.218 (#1993735)
* Thu Jul 22 2021 Fedora Release Engineering  - 
1.217-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

Re: SONAME BUMP HEADS-UP: ntfs-3g update for fixing multiple CVEs

[Richard W.M. Jones]

On Tue, Aug 31, 2021 at 05:25:47PM -0400, Neal Gompa wrote:
> * libguestfs
> * ntfs-3g-system-compression

I will do these two packages.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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: SONAME BUMP HEADS-UP: ntfs-3g update for fixing multiple CVEs

[Richard W.M. Jones]

On Tue, Aug 31, 2021 at 05:25:47PM -0400, Neal Gompa wrote:
> * libguestfs
> * ntfs-3g-system-compression

I will do these two packages.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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 1996273] perl-CPANPLUS-0.9912 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version|perl-CPANPLUS-0.991.200-1.f |perl-CPANPLUS-0.991.200-1.f
   |c36 |c36
   |perl-CPANPLUS-0.991.200-1.f |perl-CPANPLUS-0.991.200-1.f
   |c35 |c35
   ||perl-CPANPLUS-0.991.200-1.f
   ||c34
Last Closed||2021-08-31 22:02:08



--- Comment #3 from Fedora Update System  ---
FEDORA-2021-6800794716 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1996268] perl-Module-CoreList-5.20210820 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021
   |0820-1.fc36 |0820-1.fc36
   |perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021
   |0820-1.fc35 |0820-1.fc35
   |perl-Module-CoreList-5.2021 |perl-Module-CoreList-5.2021
   |0820-1.fc34 |0820-1.fc34
   ||perl-Module-CoreList-5.2021
   ||0820-1.fc33



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-65fcd15e67 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1996267] perl-CPAN-Perl-Releases-5.20210821 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0210821-1.fc36  |0210821-1.fc36
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0210821-1.fc35  |0210821-1.fc35
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0210821-1.fc34  |0210821-1.fc34
   ||perl-CPAN-Perl-Releases-5.2
   ||0210821-1.fc33



--- Comment #6 from Fedora Update System  ---
FEDORA-2021-50da017a9e has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1996267] perl-CPAN-Perl-Releases-5.20210821 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
   Fixed In Version|perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0210821-1.fc36  |0210821-1.fc36
   |perl-CPAN-Perl-Releases-5.2 |perl-CPAN-Perl-Releases-5.2
   |0210821-1.fc35  |0210821-1.fc35
   ||perl-CPAN-Perl-Releases-5.2
   ||0210821-1.fc34
Last Closed||2021-08-31 22:02:02



--- Comment #5 from Fedora Update System  ---
FEDORA-2021-f456e8fac8 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: Package Maintainer Docs published

[Otto Urpelainen]

Vít Ondruch kirjoitti 31.8.2021 klo 11.43:


Dne 31. 08. 21 v 7:39 Otto Urpelainen napsal(a):

Greetings,

Some months ago, I announced [0] that I will move the package 
maintainer docs from wiki to docs.fedoraproject.org.



Thx a lot.



All changes to the documentation is intended to happen through pull
requests. However, following the spirit of earlier wiki based
documentation, the documentation is intended to be maintainer
collectively by all Fedora packagers.

Due to technical issues, the packager group from Fedora Account
System cannot be granted access, so there is a separate group
package-maintainer-docs with commit access. Membership is granted to
any packager requesting it. Please file an issue in the repository if
you want to join.




Everybody whose PR was accepted should get commit bit IMO. 


So you mean that even people not in the 'packager' group would be 
granted access after they have one accepted PR? Sounds reasonable, there 
is still some minimal barrier of entry to block spam and such, and would 
help getting the parts that are relevant to new contributors fixed.


Also, it 
would probably help it there was explained how to get some attention if 
nobody responds to PR.


Yes, this is needed. Perhaps something like this: If your pull request 
is simple and you have commit rights, just merge it. If you do not have 
commit rights, or the change is not simple and really would need a 
review, notify people marked as repo admins by mentioning them in a 
comment. If that does not lead anywhere, complain in the devel list.


I suppose direct commits for trivial changes like typo fixes and broken 
links could be recommended, too.


Otto
___
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] SONAME BUMP HEADS-UP: ntfs-3g update for fixing multiple CVEs

[Neal Gompa]

Hey all,

ntfs-3g 2021.8.22 was released yesterday to resolve multiple CVEs[1].
With permission from Tom Callaway (the ntfs-3g maintainer), I am
preparing updates for Fedora and EPEL now for Tom.

As part of this, I'll rebuild all reverse dependencies for this. Based
on a repoquery, that is:

* libguestfs
* ntfs-3g-system-compression
* partclone
* testdisk
* wimlib

Sorry for the inconvenience.

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

-- 
真実はいつも一つ！/ 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

SONAME BUMP HEADS-UP: ntfs-3g update for fixing multiple CVEs

[Neal Gompa]

Hey all,

ntfs-3g 2021.8.22 was released yesterday to resolve multiple CVEs[1].
With permission from Tom Callaway (the ntfs-3g maintainer), I am
preparing updates for Fedora and EPEL now for Tom.

As part of this, I'll rebuild all reverse dependencies for this. Based
on a repoquery, that is:

* libguestfs
* ntfs-3g-system-compression
* partclone
* testdisk
* wimlib

Sorry for the inconvenience.

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

-- 
真実はいつも一つ！/ 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: I think we should stop building i686 packages we're not shipping

[Fabio Valentini]

On Tue, Aug 31, 2021 at 7:43 PM Matthew Miller  wrote:
>
> On Tue, Aug 31, 2021 at 12:21:54PM -0500, Justin Forbes wrote:
> > While it might take a good bit of time to sit down and figure out
> > exactly what is *useful* from a multilib standpoint, I don't think
> > that is necessary at this time. It really could be simplified to "do I
> > build a library or not?". if the package ships a library, keep
> > building it for i686, if not, you can disable it.  It isn't an optimal
> > solution, but it would probably cut down considerably on build time,
> > and resource usage.
>
> That's basically the logic used for pulling the i686 packages into the
> x86_64 repo already (plus extra include/don't-include lists), right?

If we want to reduce the number of packages that get built for i686, I
wonder if it wouldn't be easier to *only* have a list of *included*
packages rather than a list of *excluded* packages? The number of
packages that are required for x86_64/i686 multilib isn't that big,
maintaining such a list should be less work than excluding more and
more packages.

However: Do we actually need multilib for anything (other than maybe
wine)? For example, I am running Steam on my workstation, and some
Linux-native games, but I still have *zero* .i686 arch packages
installed on my system. The Steam flatpak does not need them at all,
since the freedesktop runtime comes with an i686 multilib extension
that automatically gets pulled in when the Steam flatpak is installed,
obviating the need for any i686 libraries on the host.

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

FedoraRespin-34-updates-20210831.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 4/45 (x86_64)

ID: 964322  Test: x86_64 Workstation-live-iso desktop_fprint
URL: https://openqa.fedoraproject.org/tests/964322
ID: 964333  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/964333
ID: 964337  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/964337
ID: 964346  Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/964346

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

ID: 964317  Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/964317

Passed openQA tests: 40/45 (x86_64)
-- 
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: I think we should stop building i686 packages we're not shipping

[Josh Boyer]

On Tue, Aug 31, 2021 at 12:54 PM Matthew Miller
 wrote:
>
> This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
> build stuff like libreoffice for i686, but then (mostly) don't ship it.
> This seems like a waste of resources and time.
>
> I know it's somewhat complicated (for example, there's actually a library
> package in libreoffice, libreofficekit, so that gets plucked in to
> multilib), and there's quite a lot to work out, but ... does this seem like
> a good intended direction?

Are you looking to save people resources or machine resources?

If you're worried about people spending excessive amounts of time
debugging and fixing i686 build failures, then your solution might not
be a bad one.  We wouldn't have to maintain an exception list as
Florian implied.  We'd just empower maintainers to disable i686 builds
via ExcludeArch for leaf packages.  That has potential to be
disruptive to users, but there's no graceful path in stopping
something.  The largest concern would be if a maintainer did that for
a non-leaf package, because that has implications for other
maintainers.

If things are mostly building fine and you're worried about storage or
builder capacity, I'd ask if there are actual concerns or just a "this
seems wasteful" perspective.  If there is no inherent bottleneck or
capacity limits we're pushing against, wasting a machine's time seems
fine.  It's why we invented them.  If the cumulative effect there is
that it's taking a LOT of resources even if there isn't a capacity
problem, then scale can indeed be a concerning factor.

In either case, it seems like what you're actually trying to calculate
is cost/benefit ratio.  I think we've long passed the time when i686
builds were worth it, but we keep doing it because we can think of
cases where it might be useful.  It's the same reason I have a cabinet
full of DVDs but no functional DVD player and stream everything
anyway.  Maybe someday I'd want to watch a DVD?  Might as well keep
them.

/me writes down "rip all my DVDs" on the todo list he'll never read again

josh

> One immediate way to do this is to start adding `ExcludeArch: i686` to
> "leaf" packages (I mean: to allow / encourage people to do that). But I
> don't want to add _more_ cruft to the standard minimal spec file, so this
> seems like the wrong direction. And I still think we want to keep multilib
> for compatibility (hello, old games!). Could we do something clever in koji
> instead?
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam 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

Re: openbabel-3.1* in Rawhide

[Alexander Ploumistos]

On Tue, Aug 31, 2021 at 6:08 PM Antonio T. sagitter
 wrote:
>
> On 8/31/21 5:27 PM, Alexander Ploumistos wrote:
> >
>
> We must decide if go forward with most recent software or stay stationary.
> Which software are not ready for openbabel-3 yet?

Almost two years ago (how time flies!), when the subject had been
first broached, Dominik provided this list:

Link-time dependencies:
IQmol
avogadro
ghemical
gnome-chemistry-utils
kalzium
molsketch
xdrawchem

Run-time dependencies:
avogadro2
chemtool
molsketch


At the time, I think only Molsketch was compatible with Open Babel 3.
After getting version 3.1.1 to build[1], I spent a few weekends trying
to modify gnome-chemistry-utils, but due to lack of time I didn't go
very far and looking at the code in my files, I'm not really sure what
I've actually done, I don't remember much. Personally, I use avogadro*
a lot, which you maintain (and therefore I don't worry about it ;) )
and GChemCalc (almost daily) and sometimes GSpectrum from g-c-u,
neither of which is indispensable, though both are quite handy. I
haven't checked any of the other programs on that list recently, but
about a year ago, not much had changed.


> I can leave to you an openbabel-3 srpm or Copr builds of it for your tests.
>
> One week is a minimal time, no problem if you need more time.
>

As far as I can tell, Molsketch will use whichever version of Open
Babel is installed on the system and users of a couple of other
distros have been building it against v3 without any problems, so I
don't expect any either. Just please let me know when you've built it
in Rawhide and I'll do the rebuild then - hopefully the new version
will also be out by that time.


Best regards,
A.


1. https://copr.fedorainfracloud.org/coprs/alexpl/openbabel/builds/
___
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 1999019] perl-Storable-3.25 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: I think we should stop building i686 packages we're not shipping

[Matthew Miller]

On Tue, Aug 31, 2021 at 12:21:54PM -0500, Justin Forbes wrote:
> While it might take a good bit of time to sit down and figure out
> exactly what is *useful* from a multilib standpoint, I don't think
> that is necessary at this time. It really could be simplified to "do I
> build a library or not?". if the package ships a library, keep
> building it for i686, if not, you can disable it.  It isn't an optimal
> solution, but it would probably cut down considerably on build time,
> and resource usage.

That's basically the logic used for pulling the i686 packages into the
x86_64 repo already (plus extra include/don't-include lists), right?

-- 
Matthew Miller

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

Re: I think we should stop building i686 packages we're not shipping

[Florian Weimer]

* Justin Forbes:

> On Tue, Aug 31, 2021 at 12:14 PM Florian Weimer  wrote:
>>
>> * Matthew Miller:
>>
>> > This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
>> > build stuff like libreoffice for i686, but then (mostly) don't ship it.
>> > This seems like a waste of resources and time.
>> >
>> > I know it's somewhat complicated (for example, there's actually a library
>> > package in libreoffice, libreofficekit, so that gets plucked in to
>> > multilib), and there's quite a lot to work out, but ... does this seem like
>> > a good intended direction?
>> >
>> > One immediate way to do this is to start adding `ExcludeArch: i686` to
>> > "leaf" packages (I mean: to allow / encourage people to do that). But I
>> > don't want to add _more_ cruft to the standard minimal spec file, so this
>> > seems like the wrong direction. And I still think we want to keep multilib
>> > for compatibility (hello, old games!). Could we do something clever in koji
>> > instead?
>>
>> Is really a good use of our time to maintain these exclusion lists?
>>
>> We could selectively disable LTO on i686 (on other more challenging
>> stuff, if there is any).  But thinking about whether something should be
>> built on i686 seems like a distraction.
>>
>
> While it might take a good bit of time to sit down and figure out
> exactly what is *useful* from a multilib standpoint, I don't think
> that is necessary at this time. It really could be simplified to "do I
> build a library or not?". if the package ships a library, keep
> building it for i686, if not, you can disable it.  It isn't an optimal
> solution, but it would probably cut down considerably on build time,
> and resource usage.

Our buildroots are not multilib.  We absolutely need m4.i686 even though
it does not provide any libraries.  Turning buildroots into multilib
configurations would perhaps be nice (because it would allow us to get
rid of glibc32 trivially), but it's also not something that delivers
returns into the indefinite future.  There seem to be Koji/mock
development tasks which much higher rewards.

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

Re: I think we should stop building i686 packages we're not shipping

[Nicolas Chauvet]

Le mar. 31 août 2021 à 19:22, Justin Forbes  a écrit :
>
> On Tue, Aug 31, 2021 at 12:14 PM Florian Weimer  wrote:
..
> While it might take a good bit of time to sit down and figure out
> exactly what is *useful* from a multilib standpoint, I don't think
> that is necessary at this time. It really could be simplified to "do I
> build a library or not?". if the package ships a library, keep
> building it for i686, if not, you can disable it.  It isn't an optimal
> solution, but it would probably cut down considerably on build time,
> and resource usage.

Unfortunately, some binaries (i686) are sometimes needed when building
a library, especially as we don't "cross-compile", so the first binary
needed will be gcc (which also has few libraries).
Because of that, drawing the line between what is needed for multilibs
and what's not is a moving target. As some dependencies might "change"
for a given library.

We are currently experiencing that in "3rd part" as we are only
building a limited set of packages for i686. (because the way i686
repository is only provided in koji vs normal repositories).
Maintaining an i686 buildroot synchronized from koji adds some
dependencies for the same set of i686 packages to build.

-
Nicolas
___
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: I think we should stop building i686 packages we're not shipping

[Richard W.M. Jones]

On Tue, Aug 31, 2021 at 12:53:55PM -0400, Matthew Miller wrote:
> This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
> build stuff like libreoffice for i686, but then (mostly) don't ship it.
> This seems like a waste of resources and time.
> 
> I know it's somewhat complicated (for example, there's actually a library
> package in libreoffice, libreofficekit, so that gets plucked in to
> multilib), and there's quite a lot to work out, but ... does this seem like
> a good intended direction?
> 
> One immediate way to do this is to start adding `ExcludeArch: i686` to
> "leaf" packages (I mean: to allow / encourage people to do that). But I
> don't want to add _more_ cruft to the standard minimal spec file, so this
> seems like the wrong direction. And I still think we want to keep multilib
> for compatibility (hello, old games!). Could we do something clever in koji
> instead?

Building nbdkit (not a library) for i686 recently revealed a build
problem on 32 bit platforms.  i686 and armv7 are the only 32 bit
platforms left.

https://gitlab.com/nbdkit/nbdkit/-/commit/fe6538aafe5f8d6fc6b90ae8f6d3686c711288fd

Martin:

Can we add 32 bit to the upstream CI?  You don't actually need a 32
bit environment to test it, you can do this instead:
  export CFLAGS="-g -O2 -m32"
  export CXXFLAGS="-g -O2 -m32"
  export LDFLAGS="-g -O2 -m32"
  ./configure
  make

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: I think we should stop building i686 packages we're not shipping

[Justin Forbes]

On Tue, Aug 31, 2021 at 12:14 PM Florian Weimer  wrote:
>
> * Matthew Miller:
>
> > This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
> > build stuff like libreoffice for i686, but then (mostly) don't ship it.
> > This seems like a waste of resources and time.
> >
> > I know it's somewhat complicated (for example, there's actually a library
> > package in libreoffice, libreofficekit, so that gets plucked in to
> > multilib), and there's quite a lot to work out, but ... does this seem like
> > a good intended direction?
> >
> > One immediate way to do this is to start adding `ExcludeArch: i686` to
> > "leaf" packages (I mean: to allow / encourage people to do that). But I
> > don't want to add _more_ cruft to the standard minimal spec file, so this
> > seems like the wrong direction. And I still think we want to keep multilib
> > for compatibility (hello, old games!). Could we do something clever in koji
> > instead?
>
> Is really a good use of our time to maintain these exclusion lists?
>
> We could selectively disable LTO on i686 (on other more challenging
> stuff, if there is any).  But thinking about whether something should be
> built on i686 seems like a distraction.
>

While it might take a good bit of time to sit down and figure out
exactly what is *useful* from a multilib standpoint, I don't think
that is necessary at this time. It really could be simplified to "do I
build a library or not?". if the package ships a library, keep
building it for i686, if not, you can disable it.  It isn't an optimal
solution, but it would probably cut down considerably on build time,
and resource usage.

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

Re: I think we should stop building i686 packages we're not shipping

[Florian Weimer]

* Matthew Miller:

> This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
> build stuff like libreoffice for i686, but then (mostly) don't ship it.
> This seems like a waste of resources and time.
>
> I know it's somewhat complicated (for example, there's actually a library
> package in libreoffice, libreofficekit, so that gets plucked in to
> multilib), and there's quite a lot to work out, but ... does this seem like
> a good intended direction?
>
> One immediate way to do this is to start adding `ExcludeArch: i686` to
> "leaf" packages (I mean: to allow / encourage people to do that). But I
> don't want to add _more_ cruft to the standard minimal spec file, so this
> seems like the wrong direction. And I still think we want to keep multilib
> for compatibility (hello, old games!). Could we do something clever in koji
> instead?

Is really a good use of our time to maintain these exclusion lists?

We could selectively disable LTO on i686 (on other more challenging
stuff, if there is any).  But thinking about whether something should be
built on i686 seems like a distraction.

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

Re: Package Maintainer Docs published

[kevin]

On Tue, Aug 31, 2021 at 07:27:50AM +, Mattia Verga via devel wrote:
> Il 31/08/21 07:39, Otto Urpelainen ha scritto:
> > Greetings,
> >
> > Some months ago, I announced [0] that I will move the package maintainer
> > docs from wiki to docs.fedoraproject.org. I am happy to announce that
> > this task is complete and the docs are public in their new location now
> > [1]. Hopefully, this will allow existing and new packagers to find
> > relevant documentation more easily, and foster more concentrated efforts
> > to make it better.
> >
> Thanks for this work!
> 
> Just a question from a quick reading of the Joining the Package
> Maintainers section: now that Bugzilla is integrated with the Fedora
> Account System (we can login with that) is it still mandatory to create
> a BZ account? Or should we make new users to login in BZ with FAS
> (noggin) to have the account created in BZ? How does that work?

It would create it. However, I think we should wait on this a bit
longer. The new account system has a bugzilla account field in it.
We are close to ready to make that work as you expect (ie, if you put an
account name in there it will use that as your bugzilla login/account),
but it needs some more work with bugzilla admins before it's live. 
Right now, you just get your primary email address.

kevin


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

Re: Weird Koji build failure

[kevin]

On Tue, Aug 31, 2021 at 10:25:37AM -0500, Justin Forbes wrote:
> 
> No, this was added to one build at the request of releng because
> composes are randomly failing in kernel-core %post. As we just call
> kernel-install, we first tried calling kernel-install -v, but that
> doesn't give much useful information because it doesn't seem to add
> any verbosity to the subtasks it runs. The 5.14.0-61 build was done
> last night to try and gather some more information for them, and the
> strace call is expected to disappear with the next build.  In fact,
> once they have run the composes and gotten the information needed, 61
> can be untagged, and 60 will be the same kernel without the debugging
> calls to kernel-install.  It should only impact the very few packages
> which have kernel-core as a buildreq.

Yeah, sorry to have confused anyone here. We were trying to track down
this anoying sporadic failure in kernel-core trigger/new-kernel-pkg. 

Unfortunately, it caused this OOM issue on ppc64le, so it didn't in the
end help us much. I have untagged that kernel and killed the stuck
rawhide compose. 

I'm going to see if I can get it to happen with scratch livemedia
against a sidetag with that kernel tagged in now. :( 

kevin


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

I think we should stop building i686 packages we're not shipping

[Matthew Miller]

This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
build stuff like libreoffice for i686, but then (mostly) don't ship it.
This seems like a waste of resources and time.

I know it's somewhat complicated (for example, there's actually a library
package in libreoffice, libreofficekit, so that gets plucked in to
multilib), and there's quite a lot to work out, but ... does this seem like
a good intended direction?

One immediate way to do this is to start adding `ExcludeArch: i686` to
"leaf" packages (I mean: to allow / encourage people to do that). But I
don't want to add _more_ cruft to the standard minimal spec file, so this
seems like the wrong direction. And I still think we want to keep multilib
for compatibility (hello, old games!). Could we do something clever in koji
instead?


-- 
Matthew Miller

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

Re: openbabel-3.1* in Rawhide

[Antonio T. sagitter]

On 8/31/21 5:27 PM, Alexander Ploumistos wrote:

Hello Antonio,


Hi Alexander.



On Tue, Aug 31, 2021 at 5:03 PM Antonio T. sagitter
 wrote:


openbabel-3.1.1 is ready for Rawhide branch. 'libopenbabel' soname is
updated from 5 to 7, all dependent packages will need a rebuild at least:


What about the packages that haven't been ported to work with Open
Babel 3.* yet? 


We must decide if go forward with most recent software or stay stationary.
Which software are not ready for openbabel-3 yet?

> Do you intend to keep v2 around in some form?

No.





$ repoquery --whatrequires openbabel-devel --disablerepo=*
--enablerepo=*-source

molsketch-0:0.7.2-1.fc34.src


I'm waiting for Hendrik to release a new version sometime soon, at
worst let it FTBFS and I'll deal with it in time.


I can leave to you an openbabel-3 srpm or Copr builds of it for your tests.

One week is a minimal time, no problem if you need more time.




All the best,
A.
___
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



--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keyserver1.pgp.com/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: OpenPGP public key


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

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

[tdawson]

Dear all,

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

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

A general agenda is the following:

#meetingname EPEL
#topic Intros
#topic Old Business
#topic EPEL-7
#topic EPEL-8
#topic EPEL-9
#topic Openfloor
#endmeeting




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

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

Re: openbabel-3.1* in Rawhide

[Alexander Ploumistos]

Hello Antonio,

On Tue, Aug 31, 2021 at 5:03 PM Antonio T. sagitter
 wrote:
>
> openbabel-3.1.1 is ready for Rawhide branch. 'libopenbabel' soname is
> updated from 5 to 7, all dependent packages will need a rebuild at least:

What about the packages that haven't been ported to work with Open
Babel 3.* yet? Do you intend to keep v2 around in some form?


> $ repoquery --whatrequires openbabel-devel --disablerepo=*
> --enablerepo=*-source
>
> molsketch-0:0.7.2-1.fc34.src

I'm waiting for Hendrik to release a new version sometime soon, at
worst let it FTBFS and I'll deal with it in time.


All the best,
A.
___
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: Weird Koji build failure

[Justin Forbes]

On Tue, Aug 31, 2021 at 9:41 AM Richard W.M. Jones  wrote:
>
> On Tue, Aug 31, 2021 at 10:29:27AM -0400, Neal Gompa wrote:
> > On Tue, Aug 31, 2021 at 10:13 AM Daniel P. Berrangé  
> > wrote:
> > >
> > > On Tue, Aug 31, 2021 at 10:07:38AM +0100, Richard W.M. Jones wrote:
> > > >
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=74840901
> > > >
> > > > How should I interpret this?
> > >
> > > Very odd
> > >
> > > Looking at the parent task:
> > >
> > >   https://koji.fedoraproject.org/koji/taskinfo?taskID=74840893
> > >
> > > and picking ppc64 arch instead, it gets even wierder. The root.log file:
> > >
> > >   https://kojipkgs.fedoraproject.org//work/tasks/903/74840903/root.log
> > >
> > >
> > > contains strace logs:
> > >
> > > DEBUG util.py:446:  execve("/bin/kernel-install", ["/bin/kernel-install", 
> > > "-v", "add", "5.14.0-61.fc36.ppc64le", 
> > > "/lib/modules/5.14.0-61.fc36.ppc64le/vmlinuz"], 0x7fffc420e508 /* 12 vars 
> > > */) = 0
> > > DEBUG util.py:446:  brk(NULL)   = 0x13c87
> > > DEBUG util.py:446:  readlink("/proc/self/exe", "/usr/bin/bash", 4096) = 13
> > > DEBUG util.py:446:  openat(AT_FDCWD, 
> > > "/var/tmp/tmp.mock.gzh1qs1v/lib64/nosync.so", O_RDONLY|O_CLOEXEC) = 3
> > > ...snip...
> > >
> > >
> > > What on earth is going on there ?
> > >
> > > Who would be running strace on a *production* build system host ?
> > >
> >
> > Apparently us: 
> > https://src.fedoraproject.org/rpms/kernel/c/6b7647647610ebe404bd27c768e5df1727334c32
>
> Is this related to the OOM issues in Koji, or something else?
>
> (In fact now I ask that question I wonder if this could somehow be
> _causing_ the OOM issues ...)
>

No, this was added to one build at the request of releng because
composes are randomly failing in kernel-core %post. As we just call
kernel-install, we first tried calling kernel-install -v, but that
doesn't give much useful information because it doesn't seem to add
any verbosity to the subtasks it runs. The 5.14.0-61 build was done
last night to try and gather some more information for them, and the
strace call is expected to disappear with the next build.  In fact,
once they have run the composes and gotten the information needed, 61
can be untagged, and 60 will be the same kernel without the debugging
calls to kernel-install.  It should only impact the very few packages
which have kernel-core as a buildreq.

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

openbabel-3.1* in Rawhide

[Antonio T. sagitter]

Hi all.

openbabel-3.1.1 is ready for Rawhide branch. 'libopenbabel' soname is 
updated from 5 to 7, all dependent packages will need a rebuild at least:


$ repoquery --whatrequires openbabel-devel --disablerepo=* 
--enablerepo=*-source


IQmol-0:2.15.0-3.fc34.src

ghemical-0:3.0.0-16.fc34.src

molsketch-0:0.7.2-1.fc34.src

xdrawchem-0:1.10.2-4.fc34.src


I'm waiting some days (one week around) before creating a side-tag.

Ragards.
--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keyserver1.pgp.com/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: OpenPGP public key


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

Re: Where has the kernel-doc package gone?

[stan via devel]

On Mon, 30 Aug 2021 17:07:21 -
"Nils K"  wrote:

> I recently had to perform a bit of development/research where I often
> had to take a look in the kernel documentation.
> 
> Most of the time was spend offline so I wanted to download the
> `kernel-doc` package however it does not seem to exist. Some old
> fedora documentations still refer to it however somewhere in the 2x
> iteration of fedora it seems to have gone missing. CentOS 8 also
> still has it. Would it be possible to add this back to the repos?

Easiest would be go to the kernel.org page and use the savepage
entry in the File menu of the browser to save a copy of the
documentation.  Then you can access it offline.

A more involved and clumsy workaround is to download the src.rpm
package [1] and unpack it. It is a little complicated because you have
to run 
rpmdev-setuptree
to create the ~/rpmbuild heirarchy of directories and then
rpm -ivh [src.rpm]
[***NOT*** as root] to install the src.rpm in ~/rpmbuild and then
rpmbuild -bp kernel.spec
in ~/rpmbuild/SPECS
to expand the source.

The source tree containing all the documentation will then be under
~/rpmbuild/BUILD/kernel[...]/linux[...]/Documentation

1. https://koji.fedoraproject.org/koji/packageinfo?packageID=8

___
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: Weird Koji build failure

[Richard W.M. Jones]

On Tue, Aug 31, 2021 at 10:29:27AM -0400, Neal Gompa wrote:
> On Tue, Aug 31, 2021 at 10:13 AM Daniel P. Berrangé  
> wrote:
> >
> > On Tue, Aug 31, 2021 at 10:07:38AM +0100, Richard W.M. Jones wrote:
> > >
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=74840901
> > >
> > > How should I interpret this?
> >
> > Very odd
> >
> > Looking at the parent task:
> >
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=74840893
> >
> > and picking ppc64 arch instead, it gets even wierder. The root.log file:
> >
> >   https://kojipkgs.fedoraproject.org//work/tasks/903/74840903/root.log
> >
> >
> > contains strace logs:
> >
> > DEBUG util.py:446:  execve("/bin/kernel-install", ["/bin/kernel-install", 
> > "-v", "add", "5.14.0-61.fc36.ppc64le", 
> > "/lib/modules/5.14.0-61.fc36.ppc64le/vmlinuz"], 0x7fffc420e508 /* 12 vars 
> > */) = 0
> > DEBUG util.py:446:  brk(NULL)   = 0x13c87
> > DEBUG util.py:446:  readlink("/proc/self/exe", "/usr/bin/bash", 4096) = 13
> > DEBUG util.py:446:  openat(AT_FDCWD, 
> > "/var/tmp/tmp.mock.gzh1qs1v/lib64/nosync.so", O_RDONLY|O_CLOEXEC) = 3
> > ...snip...
> >
> >
> > What on earth is going on there ?
> >
> > Who would be running strace on a *production* build system host ?
> >
> 
> Apparently us: 
> https://src.fedoraproject.org/rpms/kernel/c/6b7647647610ebe404bd27c768e5df1727334c32

Is this related to the OOM issues in Koji, or something else?

(In fact now I ask that question I wonder if this could somehow be
_causing_ the OOM issues ...)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
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: Weird Koji build failure

[Neal Gompa]

On Tue, Aug 31, 2021 at 10:13 AM Daniel P. Berrangé  wrote:
>
> On Tue, Aug 31, 2021 at 10:07:38AM +0100, Richard W.M. Jones wrote:
> >
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=74840901
> >
> > How should I interpret this?
>
> Very odd
>
> Looking at the parent task:
>
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=74840893
>
> and picking ppc64 arch instead, it gets even wierder. The root.log file:
>
>   https://kojipkgs.fedoraproject.org//work/tasks/903/74840903/root.log
>
>
> contains strace logs:
>
> DEBUG util.py:446:  execve("/bin/kernel-install", ["/bin/kernel-install", 
> "-v", "add", "5.14.0-61.fc36.ppc64le", 
> "/lib/modules/5.14.0-61.fc36.ppc64le/vmlinuz"], 0x7fffc420e508 /* 12 vars */) 
> = 0
> DEBUG util.py:446:  brk(NULL)   = 0x13c87
> DEBUG util.py:446:  readlink("/proc/self/exe", "/usr/bin/bash", 4096) = 13
> DEBUG util.py:446:  openat(AT_FDCWD, 
> "/var/tmp/tmp.mock.gzh1qs1v/lib64/nosync.so", O_RDONLY|O_CLOEXEC) = 3
> ...snip...
>
>
> What on earth is going on there ?
>
> Who would be running strace on a *production* build system host ?
>

Apparently us: 
https://src.fedoraproject.org/rpms/kernel/c/6b7647647610ebe404bd27c768e5df1727334c32




--
真実はいつも一つ！/ 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: Weird Koji build failure

[Daniel P . Berrangé]

On Tue, Aug 31, 2021 at 10:07:38AM +0100, Richard W.M. Jones wrote:
> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=74840901
> 
> How should I interpret this?

Very odd

Looking at the parent task:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=74840893

and picking ppc64 arch instead, it gets even wierder. The root.log file:

  https://kojipkgs.fedoraproject.org//work/tasks/903/74840903/root.log


contains strace logs:

DEBUG util.py:446:  execve("/bin/kernel-install", ["/bin/kernel-install", "-v", 
"add", "5.14.0-61.fc36.ppc64le", 
"/lib/modules/5.14.0-61.fc36.ppc64le/vmlinuz"], 0x7fffc420e508 /* 12 vars */) = 0
DEBUG util.py:446:  brk(NULL)   = 0x13c87
DEBUG util.py:446:  readlink("/proc/self/exe", "/usr/bin/bash", 4096) = 13
DEBUG util.py:446:  openat(AT_FDCWD, 
"/var/tmp/tmp.mock.gzh1qs1v/lib64/nosync.so", O_RDONLY|O_CLOEXEC) = 3
...snip...


What on earth is going on there ?

Who would be running strace on a *production* build system host ?

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

Re: Self Introduction: Juanjo Rubio

[Iago Rubio]

On Tue, 2021-08-31 at 14:00 +0200, Juanjo Rubio via devel wrote:
>   
>Hi! 
>
> 
>   
> 
>   
>
> 
>   
> 
>   
>My name is Juanjo Rubio, I am 32 and currently working in data
> science and machine learning engineering related topics. Long time
> linux user, familiar with open source software and programming
> (mainly Python) but I have personally never contributed to a Linux
> distro. 
>
> 
>   
> 
>   
>
> 
>   
> 
>   
>I have been following the mailing list lately to get exposed to
> the workflow. I haven't found exactly what task to focus on yet but I
> am hoping to get involved in the packaging process very soon.
>
> 
>   
> 
>   
>
> 
>   
> 
>   
>Have a lovely day! 

Welcome Juanjo !
___
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: Self Introduction: Juanjo Rubio

[Dominik 'Rathann' Mierzejewski]

Hello, Juanjo!

On Tuesday, 31 August 2021 at 14:00, Juanjo Rubio via devel wrote:
> Hi!
> 
> My name is Juanjo Rubio, I am 32 and currently working in data science
> and machine learning engineering related topics. Long time linux user,
> familiar with open source software and programming (mainly Python) but
> I have personally never contributed to a Linux distro.
> 
> I have been following the mailing list lately to get exposed to the
> workflow. I haven't found exactly what task to focus on yet but I am
> hoping to get involved in the packaging process very soon.

Welcome to Fedora! There are many science-focused packager groups,
including the SciTech SIG[1] and the NeuroFedora SIG[2], although you
might find the ML SIG[3] of more interest.

Regards,
Dominik

[1] https://fedoraproject.org/wiki/Category:SciTech_SIG
[2] https://docs.fedoraproject.org/en-US/neurofedora/overview/
[3] https://fedoraproject.org/wiki/SIGs/ML
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Self Introduction: Juanjo Rubio

[Juanjo Rubio via devel]

Hi!

My name is Juanjo Rubio, I am 32 and currently working in data science and 
machine learning engineering related topics. Long time linux user, familiar 
with open source software and programming (mainly Python) but I have personally 
never contributed to a Linux distro.

I have been following the mailing list lately to get exposed to the workflow. I 
haven't found exactly what task to focus on yet but I am hoping to get involved 
in the packaging process very soon.

Have a lovely day!
___
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: Weird Koji build failure

[Richard W.M. Jones]

On Tue, Aug 31, 2021 at 11:17:18AM +0200, Dan Horák wrote:
> On Tue, 31 Aug 2021 11:13:40 +0200
> Dan Horák  wrote:
> 
> > On Tue, 31 Aug 2021 10:07:38 +0100
> > "Richard W.M. Jones"  wrote:
> > 
> > > 
> > > https://koji.fedoraproject.org/koji/taskinfo?taskID=74840901
> > > 
> > > How should I interpret this?
> > 
> > something is killing the build in progress (like oomd?) and inspection
> > of the builders (looks at least x86_64 + ppc64le + s390x are affected)
> > in question is needed ...
> 
> from buildvm-s390x-22.s390.fedoraproject.org
> 
> [290483.759667] 
> oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/kojid.service,task=dnf,pid=1739780,uid=0
> [290483.759690] Out of memory: Killed process 1739780 (dnf) 
> total-vm:16787488kB, anon-rss:14531544kB, file-rss:4kB, shmem-rss:0kB, UID:0 
> pgtables:32650kB oom_score_adj:0
> [290486.777808] oom_reaper: reaped process 1739780 (dnf), now anon-rss:0kB, 
> file-rss:0kB, shmem-rss:0kB
> 
> killed dnf, that's not good ...

Here's another one, different package, different arch, but same sort
of error:

https://koji.fedoraproject.org/koji/taskinfo?taskID=74848368

It's tricky to understand from the log or the OOM report if there's a
particular package that dnf is trying to install that is causing the
problem, and which package that could be.

However I see there are other recent f36 builds that have not failed
(including glibc) so it cannot be a completely generic dnf problem:

https://koji.fedoraproject.org/koji/builds?tagID=44414

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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: Package Maintainer Docs published

[Ankur Sinha]

On Tue, Aug 31, 2021 10:43:26 +0200, Vít Ondruch wrote:
> 
> Everybody whose PR was accepted should get commit bit IMO. Also, it would
> probably help it there was explained how to get some attention if nobody
> responds to PR.

+1.

I've filed a tracker ticket where folks can comment if they'd like to
help maintain the docs:
https://pagure.io/fedora-docs/package-maintainer-docs/issue/23

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

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

[Sahana Prasad]

On Tue, Aug 31, 2021 at 12:02 PM Miro Hrončok  wrote:

> On 31. 08. 21 11:17, Sahana Prasad wrote:
> > Hi everyone,
> >
> > dnf builds well after building all OpenSSL dependent packages (in
> batches)
> > with the compat package and OpenSSL 3.0.0 beta2 version.
> > You can have a look at [1] with the side-tag f36-build-side-44794
>
> Hello Sahana,
>
> I am afraid the side tag has no builds in it:
>
>
> https://koji.fedoraproject.org/koji/builds?inherited=0=44794=-build_id=1
>

Thanks Miro, I'll check and fix it.


>
> So when you built scratch builds in it:
>
>
> https://koji.fedoraproject.org/koji/tasks?start=0=saprasad=all=toplevel=all=-id
>
> They all built with openssl 1:1.1.1k-2.fc35.
>
> Scratch builds don't "see each other".
>
> --
> 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: [Heads-up] Introduction of OpenSSL 3.0.0 in F36

[Miro Hrončok]

On 31. 08. 21 11:17, Sahana Prasad wrote:

Hi everyone,

dnf builds well after building all OpenSSL dependent packages (in batches)
with the compat package and OpenSSL 3.0.0 beta2 version.
You can have a look at [1] with the side-tag f36-build-side-44794


Hello Sahana,

I am afraid the side tag has no builds in it:

https://koji.fedoraproject.org/koji/builds?inherited=0=44794=-build_id=1

So when you built scratch builds in it:

https://koji.fedoraproject.org/koji/tasks?start=0=saprasad=all=toplevel=all=-id

They all built with openssl 1:1.1.1k-2.fc35.

Scratch builds don't "see each other".

--
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-Cloud-34-20210831.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-20210829.0):

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

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: replace memtest86+ with pcmemtest, needs maintainer

[Frank Crawford]

On Mon, 2021-08-30 at 12:35 -0700, Gordon Messmer wrote:
> On 8/30/21 12:08 PM, Hans de Goede wrote:
> > 
> > I checked the entry on a Windows multiboot system and it does not
> > have the
> > "insmod chain" line, maybe droppint that helps?
> 
> 
> Same result.  GRUB returns immediately to its menu.  I'm certain the 
> path is correct, because GRUB will report an error if it is wrong.

Don't know about pcmemtest, but what I have dual booting for Windows
is:

menuentry 'Windows 10/7 (EFI)' --class windows --class os --unrestricted {

insmod part_gpt
insmod fat
set root='hd0,gpt4'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4 --hint='hd0,gpt4'  CC13-F911
else
  search --no-floppy --fs-uuid --set=root CC13-F911
fi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

Regards
Frank

___
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

[Sahana Prasad]

Hi everyone,

dnf builds well after building all OpenSSL dependent packages (in batches)
with the compat package and OpenSSL 3.0.0 beta2 version.
You can have a look at [1] with the side-tag f36-build-side-44794

I think we are in a good state to merge OpenSSL 3.0.0 and compat packages
into rawhide.
Let me know if you think otherwise.

(There are some failing packages, that need to be looked at by respective
maintainers)

[1]
https://koji.fedoraproject.org/koji/tasks?start=0=saprasad=all=toplevel=all=-id

Thank you,
Regards,
Sahana Prasad



On Fri, Aug 20, 2021 at 11:36 AM Sahana Prasad  wrote:

>
>
> On Wed, Aug 18, 2021 at 11:11 PM Neal Gompa  wrote:
>
>> On Wed, Aug 18, 2021 at 3:55 PM Sahana Prasad  wrote:
>> >
>> > Hi everyone,
>> >
>> > No major progress on this task yet.
>> > I found out that the compat package needs some more fixing.
>> > I have more time in the coming days, so I should
>> > have an update soon hopefully.
>>
>> Let us know if you need help with getting the compat stuff fixed up.
>> We're happy to help! :)
>>
>
> Thanks Neal. It is fixed now and dnf builds well with it and OpenSSL 3.0
> in my copr repo.
> Performing some more tests now.
>
> Thank you,
> Regards,
> Sahana Prasad
>
>>
>>
>>
>> --
>> 真実はいつも一つ！/ 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
>>
>
___
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: Weird Koji build failure

[Dan Horák]

On Tue, 31 Aug 2021 11:13:40 +0200
Dan Horák  wrote:

> On Tue, 31 Aug 2021 10:07:38 +0100
> "Richard W.M. Jones"  wrote:
> 
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=74840901
> > 
> > How should I interpret this?
> 
> something is killing the build in progress (like oomd?) and inspection
> of the builders (looks at least x86_64 + ppc64le + s390x are affected)
> in question is needed ...

from buildvm-s390x-22.s390.fedoraproject.org

[290483.759667] 
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/kojid.service,task=dnf,pid=1739780,uid=0
[290483.759690] Out of memory: Killed process 1739780 (dnf) 
total-vm:16787488kB, anon-rss:14531544kB, file-rss:4kB, shmem-rss:0kB, UID:0 
pgtables:32650kB oom_score_adj:0
[290486.777808] oom_reaper: reaped process 1739780 (dnf), now anon-rss:0kB, 
file-rss:0kB, shmem-rss:0kB

killed dnf, that's not good ...


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

Re: Weird Koji build failure

[Dan Horák]

On Tue, 31 Aug 2021 10:07:38 +0100
"Richard W.M. Jones"  wrote:

> 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=74840901
> 
> How should I interpret this?

something is killing the build in progress (like oomd?) and inspection
of the builders (looks at least x86_64 + ppc64le + s390x are affected)
in question is needed ...


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

Weird Koji build failure

[Richard W.M. Jones]

https://koji.fedoraproject.org/koji/taskinfo?taskID=74840901

How should I interpret this?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
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 35 Change: Autoconf-2.71 (Self-Contained Change proposal)

[Ondrej Dubaj]

HEADS_UP:

The Change of autoconf to version 2.71 is built and done. F36FTBFS bugs are
created [1] for failed builds of packages. Most of them are caused by minor
issues and not merged pull-requests of fixes regarding autoconf-2.71
change. Hopefully have this done in a short time.

Thanks for cooperation!

Ondrej

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

On Mon, Aug 30, 2021 at 5:32 PM Fabio Valentini 
wrote:

> On Mon, Aug 30, 2021 at 5:29 PM Miro Hrončok  wrote:
> >
> > On 30. 08. 21 17:02, Fabio Valentini wrote:
> > > On Mon, Aug 30, 2021 at 11:49 AM Ondrej Dubaj 
> wrote:
> > >>
> > >> HEADS-UP:
> > >>
> > >> autoconf-2.71 is merged and built in Fedora rawhide together with the
> rest of autotools: automake-1.16-4.1 and libtool-2.4.6-43.
> > >>
> > >> In the next few days, scratch-build for each dependent package will
> be executed and failed packages F36FTBFS trackers will be created.
> > >>
> > >> Thank you all for your cooperation! Hopefully we will manage to bring
> this change to the end.
> > >
> > > Thanks for working on this!
> > >
> > > I wonder why you'll only submit test scratch builds of dependent
> > > packages, instead of "real" rebuilds for autoconf 2.71?
> >
> > That was my advice to Ondrej.
> >
> > My reasoning was that the real rebuild adds no value here, except it
> generates
> > meaningless updates for rawhide users.
>
> Ah, yeah that makes sense, since this change should only affect the
> build itself. Thanks for the explanation.
>
> 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
>
___
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: Package Maintainer Docs published

[Vít Ondruch]

Dne 31. 08. 21 v 7:39 Otto Urpelainen napsal(a):

Greetings,

Some months ago, I announced [0] that I will move the package 
maintainer docs from wiki to docs.fedoraproject.org.



Thx a lot.



All changes to the documentation is intended to happen through pull
requests. However, following the spirit of earlier wiki based
documentation, the documentation is intended to be maintainer
collectively by all Fedora packagers.

Due to technical issues, the packager group from Fedora Account
System cannot be granted access, so there is a separate group
package-maintainer-docs with commit access. Membership is granted to
any packager requesting it. Please file an issue in the repository if
you want to join.




Everybody whose PR was accepted should get commit bit IMO. Also, it 
would probably help it there was explained how to get some attention if 
nobody responds to PR.



Vít
___
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: Red Hat Bugzilla issues

[Petr Pisar]

V Wed, Aug 25, 2021 at 06:22:05PM +0200, Silvia Sánchez napsal(a):
> Hello everyone,
> 
> I was trying to file a bug following last QA meeting and turns out I
> can't.  I moved from an old laptop to a new one and in the new one I can't
> login.  I'm using the correct password and everything, but still is
> rejecting me.  And using my FAS means that I have to create a new account
> with its own password...  I don't want to go through all this hassle.  I
> just want to file a bug.
> Can someone tell me what or where is the problem?  Why the password that
> works in one laptop is not working in the other?
> Please, help and thank you
> 
> Kind regards,
> Silvia
> FAS:  Lailah

For debugging issues with Bugzilla system, I recommend you to contact
 as documents at
.

-- Petr


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

[Bug 1999019] perl-Storable-3.25 is available

[bugzilla]

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



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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-20210831.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-33-20210830.0):

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

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

[Bug 1999019] perl-Storable-3.25 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

   Fixed In Version||perl-Storable-3.25-1.fc36
 Status|ASSIGNED|MODIFIED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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

[rpms/perl-Storable] PR #1: Tests

[Jitka Plesnikova]

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

Merged pull-request:

``
Tests
``

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

Re: Package Maintainer Docs published

[Mattia Verga via devel]

Il 31/08/21 07:39, Otto Urpelainen ha scritto:
> Greetings,
>
> Some months ago, I announced [0] that I will move the package maintainer
> docs from wiki to docs.fedoraproject.org. I am happy to announce that
> this task is complete and the docs are public in their new location now
> [1]. Hopefully, this will allow existing and new packagers to find
> relevant documentation more easily, and foster more concentrated efforts
> to make it better.
>
Thanks for this work!

Just a question from a quick reading of the Joining the Package
Maintainers section: now that Bugzilla is integrated with the Fedora
Account System (we can login with that) is it still mandatory to create
a BZ account? Or should we make new users to login in BZ with FAS
(noggin) to have the account created in BZ? How does that work?

Mattia

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

Re: ARM 32-bit failure for wine

[Iago Rubio]

I see there are systems where you need to explicitly link wirh gcc exception 
handling libs with -lgcc_eh

Have been any change in the compiler stack since the last time you built it?

I am not at home right now, but in the evening I can try to build it if you 
need it.

Just let me know.


En 31 ago. 2021 8:51, en 8:51, Iago Rubio  escribió:
>Looks like a linker error due to missing exception functions.
>
>Does link with --fno-exceptions helps?
>
>
>En 31 ago. 2021 3:37, en 3:37, Michael Cronenworth 
>escribió:
>>Hi,
>>
>>I've had some life events keep me from pushing package updates for
>>about a month. My
>>attempt at pushing the latest wine update resulted in an ARM build
>>failure that
>>seems to indicate either a toolchain changes or compiler error. I
>>couldn't find any
>>Fedora 36 changes to match. Any ideas?
>>
>>Build error:
>>https://koji.fedoraproject.org/koji/getfile?taskID=74819672=DEFAULT=build.log=-4000
>>
>>Full build page:
>>https://koji.fedoraproject.org/koji/taskinfo?taskID=74819487
>>
>>Thanks,
>>Michael
>>___
>>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

Re: ARM 32-bit failure for wine

[Iago Rubio]

Looks like a linker error due to missing exception functions.

Does link with --fno-exceptions helps?


En 31 ago. 2021 3:37, en 3:37, Michael Cronenworth  escribió:
>Hi,
>
>I've had some life events keep me from pushing package updates for
>about a month. My
>attempt at pushing the latest wine update resulted in an ARM build
>failure that
>seems to indicate either a toolchain changes or compiler error. I
>couldn't find any
>Fedora 36 changes to match. Any ideas?
>
>Build error:
>https://koji.fedoraproject.org/koji/getfile?taskID=74819672=DEFAULT=build.log=-4000
>
>Full build page:
>https://koji.fedoraproject.org/koji/taskinfo?taskID=74819487
>
>Thanks,
>Michael
>___
>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