Package review sum-ump

[ycollette . nospam]

Hello,

I little sum-up about the package review I submitted.

Mamba: a virtual MIDI keyboard with also support playing SF2 soundfonts. I 
posted (by mistake) 2 packages review for this package ...
https://bugzilla.redhat.com/show_bug.cgi?id=1893711
https://bugzilla.redhat.com/show_bug.cgi?id=1887709


libsmf: This is a library to read / write MIDI files and it's a dependency of 
Mamba.
https://bugzilla.redhat.com/show_bug.cgi?id=1895696


Jamulus: A tool to perform rehearsale via internet. You can stream audio 
channels with a really low latency (around 10 ms). In this package review, 
somebody has also posted its spec file.

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

lv2lint: A tool which perform syntaxical analysis of ttl files. A ttl files is 
a text description file you find in LV2 audio plugins. It describes audio 
capability, content, etc on a LV2 file.
https://bugzilla.redhat.com/show_bug.cgi?id=1840865

I am still looking for sponsors to become packager for Fedora :)

Best regards !

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

Fedora-Cloud-33-20201124.0 compose check report

[Fedora compose checker]

No missing expected images.

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

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

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

Passed openQA tests: 6/7 (x86_64), 6/7 (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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Sheng Mao]

Hi Dan,

I am so lucky to have your support on this. I would be more than happy to take 
your "deal". It is a good opportunity for me to build up my knowledge on how to 
be a qualified packager.

Thank you!

Cheers,
Sheng
___
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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Sven Kieske]

On Mo, 2020-11-23 at 16:43 +, Daniel P. Berrangé wrote:
> I mentioned previously that we don't intend to take it. If no one else
> 
> claims it, then when it is finally deleted, we'll drop the dep.

Following up on this (sorry for off topic):

You mentioned also that the successor to numad was automatic numa balancing via 
kernel facilities.

However I did not find any meaningful documentation how this is exactly done or 
how this can be tuned, if at all.

I found the general overview here, which gives a good general introduction to 
numa but not how auto placement works:

https://www.kernel.org/doc/html/latest/admin-guide/mm/numaperf.html

I found also 
https://www.kernel.org/doc/html/latest/admin-guide/mm/numa_memory_policy.html

which talks about possible memory policys at greath length but also doesn't go 
into the topic of auto balancing.
At least numactl is mentioned which can be used to manually tweak the memory 
policy, but I don't know how that would
interfere with some automagic placement?

Am I missing something or is there no documentation on how the kernel handles 
this?
Thanks in advance for any pointers!


-- 
Mit freundlichen Grüßen / Regards

Sven Kieske
Systementwickler
 
 
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 4-6
32339 Espelkamp
 
Tel.: 05772 / 293-900
Fax: 05772 / 293-333
 
https://www.mittwald.de
 
Geschäftsführer: Robert Meyer, Florian Jürgens
 
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit 
gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar.



signature.asc
Description: This is a digitally signed message part
___
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

[Bug 1900978] New: perl-DBIx-Class-Schema-Diff-1.11 is available

[bugzilla]

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

Bug ID: 1900978
   Summary: perl-DBIx-Class-Schema-Diff-1.11 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-DBIx-Class-Schema-Diff
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.11
Current version/release in rawhide: 1.10-1.fc34
URL: http://search.cpan.org/dist/DBIx-Class-Schema-Diff/

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


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


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


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


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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Dan Čermák]

Hi Sheng,

"Sheng Mao"  writes:

> Hi Fedora developers, will someone be able to take over `fossil`? It is my 
> day-to-day source code and configuration management software. It is essential 
> to me. I hope it won't get orphaned.
>
> I have made a pull request on Pagure to upgrade fossil to 2.12.1 [1] to 
> include a CVE bug fix. In addition, I have worked with Fedora SQLite team to 
> add necessary compilation options to support advanced features in fossil [2].
>
> In long term, I will provide in-time update for this package through Pagure's 
> pull-request feature. I hope to get recognized as a trustworthy packager and 
> become a co-maintainer eventually.

I have recently become a sponsor and could help you out to become a
packager yourself, so that you can "save" fossil. Thus, let me propose a
"deal":
I will take fossil in the meantime and to prevent it from getting
retired and you will learn how to become a full fledged maintainer of
fossil in a agreed upon time frame. Once you're ready, I'll sponsor you
into the packager group and you'll take over fossil as the main
maintainer.
How does that sound to you? I'd be more than happy to help you get
started, although I think that you already have a good grasp what's
going on given the pull request that you shared.


Cheers,

Dan


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

Re: CPE Weekly: 2020-11-22

[Tom Seewald]

> On Mon, 23 Nov 2020 at 05:54, Aoife Moloney  
> What is OSBS? Please don't use undefined acronyms.

OSBS = OpenShift Build Service
___
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

Re: CPE Weekly: 2020-11-22

[Elliott Sales de Andrade]

On Mon, 23 Nov 2020 at 05:54, Aoife Moloney  wrote:
>
> ### OSBS for aarch64
> * Basic OKD 3.11 working on aarm64 with F31

What is OSBS? Please don't use undefined acronyms.

> * Working on repeating that install with F33
> * Next step will be to

This sentence is incomplete.

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

[389-devel] Please review: openldap pbkdf2 password hashers

[William Brown]

https://github.com/389ds/389-ds-base/pull/4457


—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[James Szinger]

On Mon, 23 Nov 2020 17:30:51 +0100
Andreas Tunek  wrote:

> Den lör 21 nov. 2020 kl 15:31 skrev James Szinger
> :
> 
> > On Fri, 20 Nov 2020 18:35:19 -0600
> > Brandon Nielsen  wrote:  
> > > If it has changed, it would be really great if pipewire-pulse
> > > could make it into the F33 repos so it could be easily tested.  
> >
> > I agree.  I think new software should be available and testable on a
> > stable Fedora release before it becomes default.  I’m not ready to
> > have a rawhide install on real hardware to test something that’s not
> > ready yet.  I am especially wary of a change that requires new
> > software to be written between now and beta.
> >
> >  
> 
> I think this is a way too high burden on new features. Testing in
> rawhide should be enough. Something like pipewire is also pretty easy
> to test in a Live system.

There is difference between having a feature available and making it the
default.

I fully support have pipewire replacing pulseaudio as an optional
feature.  I am opposed to making it the default without adequate
testing.  I am not even proposing a 'no regression' rule.  I am just
asking for extensive testing and real-world use, so that an informed
decision can be made about the defaults.  The proposed testing is
not enough.

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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Sheng Mao]

Hi Fedora developers, will someone be able to take over `fossil`? It is my 
day-to-day source code and configuration management software. It is essential 
to me. I hope it won't get orphaned.

I have made a pull request on Pagure to upgrade fossil to 2.12.1 [1] to include 
a CVE bug fix. In addition, I have worked with Fedora SQLite team to add 
necessary compilation options to support advanced features in fossil [2].

In long term, I will provide in-time update for this package through Pagure's 
pull-request feature. I hope to get recognized as a trustworthy packager and 
become a co-maintainer eventually.

Thank you!

Sheng (ivzhh)


Links:

[1] https://src.fedoraproject.org/rpms/fossil/pull-request/1
[2] https://src.fedoraproject.org/rpms/sqlite/c/f098d1
___
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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Luya Tshimbalanga]

On 2020-11-20 2:31 p.m., Naheem Zaffar wrote:



On Fri, 20 Nov 2020 at 19:47, Brandon Nielsen > wrote:


On 11/20/20 1:28 PM, Dominique Martinet wrote:
> Ben Cotton wrote on Fri, Nov 20, 2020:
l the pipewire-pulse library (which
>> removes the pulseaudio package).
>
> Took me some time to figure out how to test:

[Snip]

Me too.

I think for current F33 / Rawhide you're expected to create some
symlinks manually:
https://gitlab.freedesktop.org/pipewire/pipewire/-/snippets/1165



I don't think this is the the correct way any longer. Lib-Pulse was 
AFAIK the initially planned drop-in replacement for pulseaudio. This 
has since been deprecated. Pipewire-Pulse AFAIK provides a separate 
pulseaudio server. I dont think it needs any linking, other than 
software activation.




Pipewire-pulse is not packaged yet. It will be great to get it available 
for Fedora 33 for testing purpose.


--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer

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

[Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-d8bc3a9874 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-d8bc3a9874`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-d8bc3a9874

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

[Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-9fa782be3e has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-9fa782be3e`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9fa782be3e

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

Re: finding recursive builddeps

[Petr Šabata]

On Sun, Nov 15, 2020 at 4:13 PM Jason Edgecombe  wrote:
>
> Hi everyone,
>
> I want to rebuild some of the fedora 33 packages for EL8 (vagrant, for 
> example), but I'm having trouble getting all of the build dependencies right. 
> I ran dnf to download the SRPMS with the --resolve option, but I'm still 
> missing dependencies when I submit the builds to copr.
>
> My current workflow is to download an RPM from Fedora 33, then submit it to 
> copr to build on the EPEL8 image in my personal COPR projects, waiting for 
> any library errors, then download those and build, repeat as needed.
>
> That workflow is tedious and I feel like there must be a better way, but I 
> don't know what that is. How can I recursively find all of the builddeps for 
> packages?
>
> Ideally, I would like some type of (semi-)automated way to  track packages on 
> Fedora and automatically build them on EL8, but I'm at a loss for how to do 
> so.
>
> Thanks,
> Jason

That is a common [bootstrapping] problem, yes.

In short, you need to query the SRPM & RPM dependencies and their
runtime and build time dependencies, recursively. You also need to do
that on every architecture (due to the potential use of conditional
build deps), so your process should involve SRPM rebuilds as the ones
you download from Fedora repos have only been built on one; and it's
random -- there's a chance you won't be able to resolve your tree if
you use those. Binary RPMs are already available for all arches so you
just need to fetch the repodata.

You can do all this on a single host and arch, don't worry. No uploads
and actual RPM builds are necessary.

Once you have your package list, just compare it to your target
distribution's package list and you have your set.

It's no longer maintained and it was rather quirky buy could try
depchase; it did exactly this when we were experimenting with fully
modular distributions:
https://github.com/fedora-modularity/depchase

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

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

[Fedora compose checker]

Missing expected images:

Xfce raw-xz armhfp

Compose FAILS proposed Rawhide gating check!
3 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 16/177 (x86_64), 15/115 (aarch64)

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

ID: 727837  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/727837
ID: 727985  Test: x86_64 universal install_kickstart_hdd
URL: https://openqa.fedoraproject.org/tests/727985
ID: 728050  Test: aarch64 universal install_kickstart_hdd@uefi
URL: https://openqa.fedoraproject.org/tests/728050

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

ID: 727805  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/727805
ID: 727806  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/727806
ID: 727813  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/727813
ID: 727814  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/727814
ID: 727817  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/727817
ID: 727818  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/727818
ID: 727819  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/727819
ID: 727855  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/727855
ID: 727857  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/727857
ID: 727905  Test: aarch64 Server-dvd-iso server_cockpit_default@uefi
URL: https://openqa.fedoraproject.org/tests/727905
ID: 727909  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/727909
ID: 727910  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/727910
ID: 727918  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/727918
ID: 727920  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/727920
ID: 727923  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/727923
ID: 727931  Test: aarch64 Server-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/727931
ID: 727956  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/727956
ID: 727963  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/727963
ID: 727977  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/727977
ID: 727995  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/727995
ID: 728023  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/728023
ID: 728032  Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/728032
ID: 728035  Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/728035
ID: 728044  Test: aarch64 universal install_cyrillic_language@uefi
URL: https://openqa.fedoraproject.org/tests/728044
ID: 728057  Test: aarch64 universal upgrade_2_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/728057
ID: 728060  Test: aarch64 universal install_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/728060
ID: 728061  Test: aarch64 universal install_with_swap@uefi
URL: https://openqa.fedoraproject.org/tests/728061
ID: 728072  Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/728072

Soft failed openQA tests: 75/177 (x86_64), 47/115 (aarch64)
(Tests completed, but using a workaround for a known bug)

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

ID: 727965  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/727965

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

ID: 727781  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/727781
ID: 727782  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/727782
ID: 727783  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/727783
ID: 727784  Test: x86_64 

Fedora rawhide compose report: 20201123.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20201121.n.0
NEW: Fedora-Rawhide-20201123.n.0

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

Size of added packages:  1.87 MiB
Size of dropped packages:0 B
Size of upgraded packages:   1.12 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20201121.n.0.iso
Image: Robotics live x86_64
Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20201121.n.0.iso
Image: Workstation raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-Rawhide-20201121.n.0.armhfp.raw.xz
Image: KDE raw-xz armhfp
Path: Spins/armhfp/images/Fedora-KDE-armhfp-Rawhide-20201121.n.0-sda.raw.xz

= ADDED PACKAGES =
Package: foma-0.9.18-0.9.20200928gitb44022c.fc34
Summary: Xerox-compatible finite-state compiler
RPMs:foma libfoma libfoma-devel
Size:1.87 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  GeographicLib-1.51-1.fc34
Old package:  GeographicLib-1.50.1-4.fc33
Summary:  Library for geographic coordinate transformations
RPMs: GeographicLib GeographicLib-devel GeographicLib-doc 
nodejs-GeographicLib octave-GeographicLib python3-GeographicLib
Size: 6.02 MiB
Size change:  3.78 KiB
Changelog:
  * Tue Aug 18 2020 Jeff Law  - 1.50.1-5
  - Fix to work with C++17 (streamoff is in std:: not std::ios::)

  * Sun Nov 22 2020 Sandro Mani  - 1.51-1
  - Update to 1.51


Package:  abi-dumper-1.2-1.fc34
Old package:  abi-dumper-1.1-13.fc33
Summary:  Tool to dump ABI of an ELF object containing DWARF debug info
RPMs: abi-dumper
Size: 47.27 KiB
Size change:  8.89 KiB
Changelog:
  * Sun Nov 22 2020 Richard Shaw  - 1.2-1
  - Update to 1.2.


Package:  barman-2.12-1.fc34
Old package:  barman-2.11-1.fc34
Summary:  Backup and Recovery Manager for PostgreSQL
RPMs: barman barman-cli python3-barman
Size: 388.37 KiB
Size change:  1.37 KiB
Changelog:
  * Sun Nov 22 2020 Francisco Javier Tsao Sant??n  - 2.12-1
  - Update to 2.12.


Package:  clustershell-1.8.3-5.fc34
Old package:  clustershell-1.8.3-3.fc33
Summary:  Python framework for efficient cluster administration
RPMs: clustershell python3-clustershell
Size: 374.86 KiB
Size change:  151 B
Changelog:
  * Mon Jul 27 2020 Fedora Release Engineering  - 
1.8.3-4
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild

  * Sat Nov 21 2020 Stephane Thiell  1.8.3-5
  - Removed unversioned __python macros 
https://fedoraproject.org/wiki/Changes/PythonMacroError [1896129]


Package:  drbd-9.15.1-1.fc34
Old package:  drbd-9.15.0-2.fc34
Summary:  DRBD user-land tools and scripts
RPMs: drbd drbd-bash-completion drbd-pacemaker drbd-rgmanager drbd-udev 
drbd-utils drbd-xen
Size: 4.08 MiB
Size change:  6.20 KiB
Changelog:
  * Sun Nov 22 2020 Peter Hanecak  - 9.15.1-1
  - Upstream release of 9.15.1


Package:  dummy-test-package-crested-0-2234
Old package:  dummy-test-package-crested-0-2225
Summary:  Dummy Test Package called Crested
RPMs: dummy-test-package-crested
Size: 143.36 KiB
Size change:  559 B
Changelog:
  * Sun Nov 22 2020 packagerbot  - 0-2226
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2227
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2228
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2229
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2230
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2231
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2232
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2233
  - rebuilt

  * Mon Nov 23 2020 packagerbot  - 0-2234
  - rebuilt


Package:  dummy-test-package-gloster-0-2120.fc34
Old package:  dummy-test-package-gloster-0-2110.fc34
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 135.19 KiB
Size change:  609 B
Changelog:
  * Sat Nov 21 2020 packagerbot  - 0-2111
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2112
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2113
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2114
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2115
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2116
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2117
  - rebuilt

  * Sun Nov 22 2020 packagerbot  - 0-2118
  - rebuilt

  * Mon Nov 23 2020 packagerbot  - 0-2119
  - rebuilt

  * Mon Nov 23 2020 packagerbot  - 0-2120
  - rebuilt


Package:  dummy-test-package-rubino-0-2234
Old package:  dummy-test-package-rubino-0-2225
Summary:  Dummy Test Package called Rubino
RPMs: dummy-test-package-rubino
Size: 143.29 KiB
Size change:  546 B
Changelog:
  * Sun Nov 22 2020

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Elliott Sales de Andrade]

On Mon, 23 Nov 2020 at 04:32, Miro Hrončok  wrote:
> golang-github-casbin  go-sig, orphan   0 weeks ago

I took this one before realizing it was v1, not v2, so I've orphaned it again.

> golang-github-cenkalti-backoffgo-sig, jchaloup, orphan 0 weeks ago
> golang-github-cespare-xxhash  go-sig, orphan   0 weeks ago

These two are needed by restic (maintainers cc'd). I can take xxhash
if you don't want it, but not so keen on backoff.

> gplugin   orphan   0 weeks ago

Taken

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

Re: GitLab AMA Topic: Message Bus

[Adam Williamson]

On Mon, 2020-11-23 at 15:11 -0500, Neal Gompa wrote:
> > 
> > I would highly recommend not creating message consumers that rely on
> > any particular message ordering because they're not going to work
> > properly, GitLab or not.
> 
> Too late, pretty much every consumer I'm aware of relies on having
> chronological order or at least some way to sort them chronologically
> for processing for messages.

I don't think any consumer I've written does. They all just work on the
basis "a thing happened; do some things relevant to the thing that
happened".
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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

Re: GitLab AMA Topic: Message Bus

[Neal Gompa]

On Mon, Nov 23, 2020 at 3:00 PM Jeremy Cline  wrote:
>
> On Mon, 2020-11-23 at 19:29 +0100, Clement Verna wrote:
> >
> >
> > On Wed, 18 Nov 2020 at 18:30, Fabio Valentini 
> > wrote:
> > > On Mon, Nov 9, 2020 at 3:05 PM Aoife Moloney 
> > > wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > I hope you enjoyed the F33 release party this weekend! Getting
> > > back to
> > > > the GitLab topic mail threads, this weeks topic from the GitLab
> > > AMA
> > > > session on September 10th is on Message Bus. As always, here are
> > > some
> > > > links to the resources I have been pulling content from as well:
> > > > * Questions and Answers hackmd link
> > > https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> > > > * Chat log from session
> > > >
> > > https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> > > > * AMA Blog post
> > > >
> > > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
> > > > * Here is this email in hackmd if you wish to view it there:
> > > > https://hackmd.io/tfOqCXNEQtqsGNLAEfZ2zg?view
> > >
> > > Sorry for taking so long to respond, the past weeks have been quite
> > > busy.
> > >
> >
> > Sorry for taking even longer to answer, you know the feeling :P
> >
> > >
> > > (snip)
> > >
> > > > ## Topic: Message Bus
> > > > - Question: Fedora uses a message bus to integrate different
> > > parts of
> > > > its infrastructure. How should we onboard GitLab into this
> > > message
> > > > bus?
> > > >  - Answer: Currently we would need to have a service that
> > > proxies
> > > > GitLab’s events to fedora-messaging something similar to
> > > > github2fedmsg.
> > > > There were some concerns raised about the order of events sent by
> > > > GitLab’s webhooks, these will need to be looked after during a
> > > Proof
> > > > of Concept stage.
> > >
> > > Do we know if such a proxy would even be theoretically possible for
> > > GitLab?
> > > IIRC, some doubts were raised during the AMA that getting a
> > > chronologically consistent stream of events out of GitLab would be
> > > ∈
> > > [hard, impossible[.
> > > What would that mean for fedora? Do services relying on
> > > fedora-messaging events related to dist-git need them to be
> > > consistent
> > > / chronological?
> > > What would be the effect of those services not having a reliable
> > > stream of events from dist-git?
> > >
> >
> > I personally don't have a good answer to these questions, and I don't
> > think we will be able to
> > have without actually doing a Proof of Concept and see how that would
> > work and scale.
> >
> > Regarding the order or messages, I believe that anything related to
> > CI testing might need to
> > have the chronological order of messages consistent.
> > I am not sure if there are any other use cases ?
> >
>
> If any service relies on chronological ordering for messaging, I've got
> bad news on that front. There's plenty of scenarios where messages can
> arrive out-of-order now, regardless of whether they were queued up
> sequentially (which, in a distributed system, with multiple nodes
> accepting messages for publication...). There's also no guarantees
> about messages only being delivered once. Never mind that GitLab's
> webhooks may well fire multiple times if a response is not received in
> a timely manner.
>
> I would highly recommend not creating message consumers that rely on
> any particular message ordering because they're not going to work
> properly, GitLab or not.

Too late, pretty much every consumer I'm aware of relies on having
chronological order or at least some way to sort them chronologically
for processing for messages.



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

Re: GitLab AMA Topic: Message Bus

[Jeremy Cline]

On Mon, 2020-11-23 at 19:29 +0100, Clement Verna wrote:
> 
> 
> On Wed, 18 Nov 2020 at 18:30, Fabio Valentini 
> wrote:
> > On Mon, Nov 9, 2020 at 3:05 PM Aoife Moloney 
> > wrote:
> > > 
> > > Hi everyone,
> > > 
> > > I hope you enjoyed the F33 release party this weekend! Getting
> > back to
> > > the GitLab topic mail threads, this weeks topic from the GitLab
> > AMA
> > > session on September 10th is on Message Bus. As always, here are
> > some
> > > links to the resources I have been pulling content from as well:
> > > * Questions and Answers hackmd link
> > https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> > > * Chat log from session
> > > 
> > https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> > > * AMA Blog post
> > > 
> > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
> > > * Here is this email in hackmd if you wish to view it there:
> > > https://hackmd.io/tfOqCXNEQtqsGNLAEfZ2zg?view
> > 
> > Sorry for taking so long to respond, the past weeks have been quite
> > busy.
> > 
> 
> Sorry for taking even longer to answer, you know the feeling :P 
>  
> > 
> > (snip)
> > 
> > > ## Topic: Message Bus
> > > - Question: Fedora uses a message bus to integrate different
> > parts of
> > > its infrastructure. How should we onboard GitLab into this
> > message
> > > bus?
> > >      - Answer: Currently we would need to have a service that
> > proxies
> > > GitLab’s events to fedora-messaging something similar to
> > > github2fedmsg.
> > > There were some concerns raised about the order of events sent by
> > > GitLab’s webhooks, these will need to be looked after during a
> > Proof
> > > of Concept stage.
> > 
> > Do we know if such a proxy would even be theoretically possible for
> > GitLab?
> > IIRC, some doubts were raised during the AMA that getting a
> > chronologically consistent stream of events out of GitLab would be
> > ∈
> > [hard, impossible[.
> > What would that mean for fedora? Do services relying on
> > fedora-messaging events related to dist-git need them to be
> > consistent
> > / chronological?
> > What would be the effect of those services not having a reliable
> > stream of events from dist-git?
> > 
> 
> I personally don't have a good answer to these questions, and I don't
> think we will be able to 
> have without actually doing a Proof of Concept and see how that would
> work and scale.
> 
> Regarding the order or messages, I believe that anything related to
> CI testing might need to 
> have the chronological order of messages consistent. 
> I am not sure if there are any other use cases ?
> 

If any service relies on chronological ordering for messaging, I've got
bad news on that front. There's plenty of scenarios where messages can
arrive out-of-order now, regardless of whether they were queued up
sequentially (which, in a distributed system, with multiple nodes
accepting messages for publication...). There's also no guarantees
about messages only being delivered once. Never mind that GitLab's
webhooks may well fire multiple times if a response is not received in
a timely manner.

I would highly recommend not creating message consumers that rely on
any particular message ordering because they're not going to work
properly, GitLab or not.

- Jeremy

___
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

[Bug 1900678] perl-Convert-Binary-C-0.84 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




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

[Bug 1899182] Upgrade perl-Type-Tie to 0.015

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Type-Tie-0.015-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2020-11-23 19:21:15



--- Comment #1 from Jitka Plesnikova  ---
Built by corsepiu


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

[Bug 1896968] perl-Mozilla-PublicSuffix-1.0.1 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Mozilla-PublicSuffix-1
   ||.0.1-1.fc34
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-11-23 19:20:20



--- Comment #1 from Jitka Plesnikova  ---
Built by yaneti


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

[Bug 1900820] New: Upgrade perl-SQL-Abstract-Limit to 0.142

[bugzilla]

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

Bug ID: 1900820
   Summary: Upgrade perl-SQL-Abstract-Limit to 0.142
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-SQL-Abstract-Limit
  Assignee: spo...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Latest Fedora delivers 0.141 version. Upstream released 0.142. When you have
free time, please upgrade it.


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

[Bug 1891478] Upgrade perl-Params-Util to 1.102

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

Summary|Upgrade perl-Params-Util to |Upgrade perl-Params-Util to
   |1.101   |1.102



--- Comment #1 from Jitka Plesnikova  ---
Latest Fedora delivers 1.07 version. Upstream released 1.102. When you have
free time, please upgrade it.


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

[Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-d8bc3a9874 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-d8bc3a9874


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

Re: GitLab AMA Topic: Message Bus

[Clement Verna]

On Wed, 18 Nov 2020 at 18:30, Fabio Valentini  wrote:

> On Mon, Nov 9, 2020 at 3:05 PM Aoife Moloney  wrote:
> >
> > Hi everyone,
> >
> > I hope you enjoyed the F33 release party this weekend! Getting back to
> > the GitLab topic mail threads, this weeks topic from the GitLab AMA
> > session on September 10th is on Message Bus. As always, here are some
> > links to the resources I have been pulling content from as well:
> > * Questions and Answers hackmd link
> https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
> > * Chat log from session
> >
> https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
> > * AMA Blog post
> > https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
> > * Here is this email in hackmd if you wish to view it there:
> > https://hackmd.io/tfOqCXNEQtqsGNLAEfZ2zg?view
>
> Sorry for taking so long to respond, the past weeks have been quite busy.
>

Sorry for taking even longer to answer, you know the feeling :P


>
> (snip)
>
> > ## Topic: Message Bus
> > - Question: Fedora uses a message bus to integrate different parts of
> > its infrastructure. How should we onboard GitLab into this message
> > bus?
> > - Answer: Currently we would need to have a service that proxies
> > GitLab’s events to fedora-messaging something similar to
> > github2fedmsg.
> > There were some concerns raised about the order of events sent by
> > GitLab’s webhooks, these will need to be looked after during a Proof
> > of Concept stage.
>
> Do we know if such a proxy would even be theoretically possible for GitLab?
> IIRC, some doubts were raised during the AMA that getting a
> chronologically consistent stream of events out of GitLab would be ∈
> [hard, impossible[.
> What would that mean for fedora? Do services relying on
> fedora-messaging events related to dist-git need them to be consistent
> / chronological?
> What would be the effect of those services not having a reliable
> stream of events from dist-git?
>

I personally don't have a good answer to these questions, and I don't think
we will be able to
have without actually doing a Proof of Concept and see how that would work
and scale.

Regarding the order or messages, I believe that anything related to CI
testing might need to
have the chronological order of messages consistent.
I am not sure if there are any other use cases ?



>
> Fabio
>
> > - Question: How would git push over http work with GitLab? (assuming
> > gitlab does not have Fedora's password since they are stored in FAS)
> > - Answer: GitLab has a good number of authentication options and
> > integrations where the "best" solution usually depends on a team's
> > specific needs and use case. As such,  the best way to know and meet
> > Fedora's needs and use cases is to have a conversation and discuss the
> > options with GitLab. How does git push over HTTP work with FAS right
> > now, and what git push (over HTTP) auth requirements/flow would you
> > like to have for your projects in GitLab?
> >
> > These are the only two questions and answers I could gather relating
> > to message bus from the AMA question sheet, however I know there was a
> > lot of discussion regarding this topic during the AMA session itself,
> > so if you would like to resume/kick off  that conversation again,
> > please feel free to use this email to discuss.
> >
> > A personal note and for full transparency: the weeks seem to be
> > passing in the blink of an eye lately, I assume it's because I'm
> > busy(?) but it might be just the weird 2020 vibe the world is on
> > nowadays. I really don't know. Whatever the reason, there has been no
> > further discussion with GitLab since early October-ish, but we will be
> > returning to the conversation of how this migration could be
> > technically possible soon, so sincerely thank you all again for
> > engaging with us/me here as I found reading the discussion on
> > permission and access much easier to follow and have been taking notes
> > on your expectations to use that feedback in conversations with GitLab
> > when we pick the discussion back up.
> >
> >
> >
> > I hope you all had a good weekend and will talk to you all next week
> > when the topic of Namespace & Issue Tracking is sent!
> >
> >
> > Kindest regards,
> > Aoife
> > --
> > Aoife Moloney
> > Product Owner
> > Community Platform Engineering Team
> > Red Hat EMEA
> > Communications House
> > Cork Road
> > Waterford
> > ___
> > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to
> devel-announce-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> ___
> 

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Brandon Nielsen]

On 11/23/20 11:48 AM, Adam Williamson wrote:

On Mon, 2020-11-23 at 18:20 +0100, Tomasz Torcz wrote:

On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote:

On 11/20/20 5:26 PM, Ben Cotton wrote:


The pulseaudio package will be uninstalled and pipewire-pulse will be installed.

pipewire-pulse does not yet implement all the features of pulseaudio
but it is expected that
comparable functionality will be implemented later. Most notable
features that are likely
not going to be available for fedora 34

IMO, this alone disqualifies this plan.

Fedora should be a stable end-user distro and not a testing site for eager
devs to test their immature and incomplete works.


   I think Fedora should establish strong "no regressions" rule when
replacing system software like this.  PulseAudio has had 15 years of
development, features and fixes.  It is hard to believe pipewire is as
capable as a replacement now.


I disagree. This would be incompatible with the "First" foundation.

If we'd had a "no regressions" rule for pre-PA audio, we'd probably
never have landed PA, or not for years. Are things on the whole better
since we did? I'd say yes.

Will our first release with pipewire probably have some bugs that
constitute regressions from the previous audio setup? Almost certainly.
Especially given the sheer amounts of stuff people do - see your config
below - I think we'd find it difficult to have a "no regressions" rule
and still be Fedora. Part of Fedora's job is to adopt new things and
shake some of the initial bugs out of them.


   Of course we would need to start with collecting the use cases, and
this will be different for every user.  For example, I frequently use my
laptop with 3 sound devices present: built-in speakers, speakers
connected to USB-C dock and bluetooth headphones*.  I use pavucontrol to
route applications to proper output/input and I expect this to work the
same with PW.  This is important to me.


Did that all work with the first Fedora with PA in it? I bet not. Would
we have as capable a PA today if Fedora hadn't taken the leap to
include PA? Probably not.

>

[Snip]


PulseAudio wasn't necessarily purporting to be a drop-in replacement for 
Alsa. It seems like if PipeWire really is going to be swappable like the 
change text notes[0], we should be looking at this as a rare opportunity 
to get really widespread testing with a potentially majorly breaking 
change by offering the ability to easily swap it in and test in already 
released versions. That way we could be "first" and "battle hardened" at 
the same time.


Unfortunately, as noted elsewhere in this thread, there really isn't a 
way to test outside of Rawhide currently[1][2][3]. It seems like the 
packages are there and should work, but might not[4]?


As I've mentioned elsewhere, I'm not saying handling changes like this 
should be mandated[5], or even required in this specific case, or 
elsewhere. But I think there would be less pushback to the change if 
this was the course of action.


[0] - "This proposal is to replace the PulseAudio daemon with a 
functionally compatible implementation based on PipeWire. This means 
that all existing clients using the PulseAudio client library will 
continue to work as before, as well as applications shipped as Flatpak."
[1] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KNQXW2XNVS4KVGHBONNWIUWXBSCRBGRV/
[2] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LITC357UASWMUBFCVDHOPOG2B4W3VMI6/
[3] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RLCQAMCUASZ764LQ2YQ7PXYKNZVVKJX7/
[4] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4OZXC2FSFPOZ5EJS4M5YNCEADIAHOGNF/
[5] - 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E262AGSRXKUZ5SYR6IP3TQ4JJMBDWKGS/

___
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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Solomon Peachy]

On Mon, Nov 23, 2020 at 09:48:56AM -0800, Adam Williamson wrote:
> If we'd had a "no regressions" rule for pre-PA audio, we'd probably
> never have landed PA, or not for years. Are things on the whole better
> since we did? I'd say yes.

You are correct; however the crucial difference between then and now is 
that PulseAudio was installable (and therefore testable) in Fedora 7 
prior to Fedora 8 making it the default.

That is not the case with PipeWire today.

> QA folks, this is definitely a Change that (if approved) we should do a
> Test Day (or several) for, and probably one that could use help with a
> better test plan. Do we have any domain experts who'd like to volunteer
> to work on that? Thanks!

If "Test Day" requires running rawhide (or booting a LiveUSB image) then 
I'm not going to be able to do meanigful testing with my actual desktop 
environment and applications.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (freenode)


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

Re: orphaning Taskotron-related packages

[Tim Flink]

On Thu, 12 Nov 2020 18:25:17 +0100
Kamil Paral  wrote:

> Note: The email subject should have said "retiring" instead of
> "orphaning". There is little reason to orphan them, retiring is the
> right approach here. Perhaps except for mongoquery, somebody else
> could be interested in maintaining that, so that one should be
> orphaned instead.

Orphaning python-mongoquery and retiring everything else makes sense to
me.

Tim


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

Fedora-IoT-33-20201123.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old failures (same test failed in Fedora-IoT-33-20201119.0):

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

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

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
System load changed from 0.21 to 0.08
Previous test data: https://openqa.fedoraproject.org/tests/725721#downloads
Current test data: https://openqa.fedoraproject.org/tests/727592#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Adam Williamson]

On Mon, 2020-11-23 at 18:20 +0100, Tomasz Torcz wrote:
> On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote:
> > On 11/20/20 5:26 PM, Ben Cotton wrote:
> > 
> > > The pulseaudio package will be uninstalled and pipewire-pulse will be 
> > > installed.
> > > 
> > > pipewire-pulse does not yet implement all the features of pulseaudio
> > > but it is expected that
> > > comparable functionality will be implemented later. Most notable
> > > features that are likely
> > > not going to be available for fedora 34
> > IMO, this alone disqualifies this plan.
> > 
> > Fedora should be a stable end-user distro and not a testing site for eager
> > devs to test their immature and incomplete works.
> 
>   I think Fedora should establish strong "no regressions" rule when
> replacing system software like this.  PulseAudio has had 15 years of
> development, features and fixes.  It is hard to believe pipewire is as
> capable as a replacement now.

I disagree. This would be incompatible with the "First" foundation.

If we'd had a "no regressions" rule for pre-PA audio, we'd probably
never have landed PA, or not for years. Are things on the whole better
since we did? I'd say yes.

Will our first release with pipewire probably have some bugs that
constitute regressions from the previous audio setup? Almost certainly.
Especially given the sheer amounts of stuff people do - see your config
below - I think we'd find it difficult to have a "no regressions" rule
and still be Fedora. Part of Fedora's job is to adopt new things and
shake some of the initial bugs out of them.

>   Of course we would need to start with collecting the use cases, and
> this will be different for every user.  For example, I frequently use my
> laptop with 3 sound devices present: built-in speakers, speakers
> connected to USB-C dock and bluetooth headphones*.  I use pavucontrol to
> route applications to proper output/input and I expect this to work the
> same with PW.  This is important to me.

Did that all work with the first Fedora with PA in it? I bet not. Would
we have as capable a PA today if Fedora hadn't taken the leap to
include PA? Probably not.

>   On the other hand, I do not use AC3 passthrough when watching movies
> and I'm not so much interested in power saving through dynamic
> latency/timers adjustment and suspending outputs.  If this ceased to
> work, _I_ wouldn't notice.  But for someone this may be crucial. The
> same for equalizer modules. Or volume ramp up. Or multiple device
> combining. And so on.

Yes, and on and on and on and on and on and on and on...

>   Right now "How to test" section of Change Proposal contains only very
> rudimentary cases like "check if rhythmbox plays".  This is not enough
> when replacing as potent software as PulseAudio.

*This*, though, I tend to agree with. "How to test" sections do tend to
be mailed in. It would be good to cover at least a range of commonly
used configurations here.

QA folks, this is definitely a Change that (if approved) we should do a
Test Day (or several) for, and probably one that could use help with a
better test plan. Do we have any domain experts who'd like to volunteer
to work on that? Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net


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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Roberto Ragusa]

On 11/23/20 5:23 PM, stan via devel wrote:

On Sun, 22 Nov 2020 15:47:04 +0100
Andy Mender  wrote:


Is ALSA still a valid use case? I thought ALSA support was phased out
from most relevant software?


It is for me.  I run some audio software that I do not want interrupted
while it is running.  So, I use pavucontrol to turn it off to pulse and
make it available only to alsa.  Then, I can directly configure, send
commands to, and use the sound device, ignored by pulse.  As near as I
can tell, it is still available in audacity, as well.

My use case for pure alsa is video grabbing of VHS tapes.
Sound is captured at alsa level, I do not want any pulseaudio in the middle.

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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Tomasz Torcz]

On Sun, Nov 22, 2020 at 06:01:18PM +0100, Ralf Corsepius wrote:
> On 11/20/20 5:26 PM, Ben Cotton wrote:
> 
> > The pulseaudio package will be uninstalled and pipewire-pulse will be 
> > installed.
> >
> > pipewire-pulse does not yet implement all the features of pulseaudio
> > but it is expected that
> > comparable functionality will be implemented later. Most notable
> > features that are likely
> > not going to be available for fedora 34
> IMO, this alone disqualifies this plan.
> 
> Fedora should be a stable end-user distro and not a testing site for eager
> devs to test their immature and incomplete works.

  I think Fedora should establish strong "no regressions" rule when
replacing system software like this.  PulseAudio has had 15 years of
development, features and fixes.  It is hard to believe pipewire is as
capable as a replacement now.

  Of course we would need to start with collecting the use cases, and
this will be different for every user.  For example, I frequently use my
laptop with 3 sound devices present: built-in speakers, speakers
connected to USB-C dock and bluetooth headphones*.  I use pavucontrol to
route applications to proper output/input and I expect this to work the
same with PW.  This is important to me.

  On the other hand, I do not use AC3 passthrough when watching movies
and I'm not so much interested in power saving through dynamic
latency/timers adjustment and suspending outputs.  If this ceased to
work, _I_ wouldn't notice.  But for someone this may be crucial. The
same for equalizer modules. Or volume ramp up. Or multiple device
combining. And so on.

  Right now "How to test" section of Change Proposal contains only very
rudimentary cases like "check if rhythmbox plays".  This is not enough
when replacing as potent software as PulseAudio.


* - for some BT codecs I need pulseaudio-module-bluetooth-freeworld

-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Brandon Nielsen]

On 11/23/20 10:30 AM, Andreas Tunek wrote:



Den lör 21 nov. 2020 kl 15:31 skrev James Szinger >:


On Fri, 20 Nov 2020 18:35:19 -0600
Brandon Nielsen mailto:niels...@jetfuse.net>>
wrote:
 > If it has changed, it would be really great if pipewire-pulse could
 > make it into the F33 repos so it could be easily tested.

I agree.  I think new software should be available and testable on a
stable Fedora release before it becomes default.  I’m not ready to
have a rawhide install on real hardware to test something that’s not
ready yet.  I am especially wary of a change that requires new
software to be written between now and beta.



I think this is a way too high burden on new features. Testing in 
rawhide should be enough. Something like pipewire is also pretty easy to 
test in a Live system.


[Snip]



Easy to test basic things like sound works, headphones work, output 
device changing works. Much more difficult to test every audio use-case 
I use in a given day, week, month, because needs and uses change so 
much. Am I using my Bluetooth headphones today? A USB audio interface? 
Webcam? HDMI? Plus I work across different systems with almost entirely 
different hardware. I may be willing to run Rawhide on some of these 
systems, but most people probably won't.


I'm not saying this should necessarily be a mandate. But for something 
completely fundamental to how a lot of people use their systems, 
especially now, with such a wide array of hardware and uses, we should 
absolutely be pursuing the widest possible test coverage. And right now, 
the only answers are "it works in rawhide" and "it will be feature 
complete later".

___
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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Daniel P . Berrangé]

On Mon, Nov 23, 2020 at 08:42:08AM -0800, Adam Williamson wrote:
> On Mon, 2020-11-23 at 10:30 +0100, Miro Hrončok wrote:
> > 
> 
> > numad orphan   3 weeks 
> > ago
> 
> Just wanted to flag this one up, because all of libvirt depends on it.
> So if no-one else wants it, someone from virt team should probably take
> it (or drop the dep).

I mentioned previously that we don't intend to take it. If no one else
claims it, then when it is finally deleted, we'll drop the dep.


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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Adam Williamson]

On Mon, 2020-11-23 at 10:30 +0100, Miro Hrončok wrote:
> 

> numad orphan   3 weeks ago

Just wanted to flag this one up, because all of libvirt depends on it.
So if no-one else wants it, someone from virt team should probably take
it (or drop the dep).
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
http://www.happyassassin.net

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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[Andreas Tunek]

Den lör 21 nov. 2020 kl 15:31 skrev James Szinger :

> On Fri, 20 Nov 2020 18:35:19 -0600
> Brandon Nielsen  wrote:
> > If it has changed, it would be really great if pipewire-pulse could
> > make it into the F33 repos so it could be easily tested.
>
> I agree.  I think new software should be available and testable on a
> stable Fedora release before it becomes default.  I’m not ready to
> have a rawhide install on real hardware to test something that’s not
> ready yet.  I am especially wary of a change that requires new
> software to be written between now and beta.
>
>

I think this is a way too high burden on new features. Testing in rawhide
should be enough. Something like pipewire is also pretty easy to test in a
Live system.

Best regards
Andreas



> Remember, there was great anger and frustration when pulseaudio became
> the default before it was ready (IMHO).  It has improved a lot since
> then.  Please learn from them and make it easy for volunteers to test
> this with real use before breaking everyone’s sound.  I have a few
> things I want to try beyond what is in the how-to-test section.
>
> Please provide simple instructions on how to test for F33/32 or defer
> the change until F35.  Overall, pipewire sounds very promising; I just
> want to be sure it is ready.
>
> Jim
> ___
> 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
>
___
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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[stan via devel]

On Sun, 22 Nov 2020 15:47:04 +0100
Andy Mender  wrote:

> Is ALSA still a valid use case? I thought ALSA support was phased out
> from most relevant software?

It is for me.  I run some audio software that I do not want interrupted
while it is running.  So, I use pavucontrol to turn it off to pulse and
make it available only to alsa.  Then, I can directly configure, send
commands to, and use the sound device, ignored by pulse.  As near as I
can tell, it is still available in audacity, as well.

alsa is going nowhere since it is the interface to the hardware that
every other sound application depends on.  It is mature so it should
take very little maintenance to allow it to remain.
___
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

[Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-9fa782be3e has been submitted as an update to Fedora 33.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-9fa782be3e


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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Peter Lemenkov]

I'll take couchdb, fop, erlang-corba, erlang-lager

пн, 23 нояб. 2020 г. в 10:31, Miro Hrončok :
>
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-11-23.txt
> grep it for your FAS username and follow the dependency chain.
>
> For human readable dependency chains, see 
> https://packager.fedorainfracloud.org/
> For all orphaned packages, see https://packager.fedorainfracloud.org/orphan
>
>  Package  (co)maintainers   Status 
> Change
> 
> Pencil2D  lbazan, orphan   0 weeks ago
> RxCpp orphan   0 weeks ago
> ansible-collection-community- orphan   3 weeks ago
> general
> apivizlef, orphan  0 weeks ago
> apper kde-sig, orphan, rhughes 0 weeks ago
> bfast orphan   0 weeks ago
> biblesync cicku, orphan0 weeks ago
> bifcl orphan   0 weeks ago
> bmon  orphan   0 weeks ago
> celt071   orphan   4 weeks ago
> colorhug-client   orphan   1 weeks ago
> compat-guile18jskarvad, mlichvar, orphan,  3 weeks ago
>tkorbar
> cook  orphan   0 weeks ago
> coolreaderorphan   0 weeks ago
> couchdb   orphan   0 weeks ago
> cpulimit  orphan   0 weeks ago
> cros-guest-tools  orphan   1 weeks ago
> dc3dd maxamillion, orphan  0 weeks ago
> dep   go-sig, orphan   0 weeks ago
> discord-irc   orphan   3 weeks ago
> dnscaporphan   4 weeks ago
> dnsjava   orphan   0 weeks ago
> dumb-init orphan   0 weeks ago
> dynaplugz orphan   0 weeks ago
> edb   orphan   0 weeks ago
> elasticdump   orphan   3 weeks ago
> electric  blackfile, orphan0 weeks ago
> electrum  orphan   4 weeks ago
> erlang-corba  orphan   0 weeks ago
> erlang-lager  bowlofeggs, orphan   0 weeks ago
> eyesight  cicku, orphan, plfiorini 0 weeks ago
> fedora-developer-portal   orphan   2 weeks ago
> fifechan  orphan   0 weeks ago
> fillets-ngorphan, thias0 weeks ago
> flaconignatenkobrain, orphan   0 weeks ago
> fmpp  orphan   0 weeks ago
> fossilorphan   0 weeks ago
> freetiger orphan   0 weeks ago
> gaupolmmraka, orphan   0 weeks ago
> ghc-pipes-safeorphan   3 weeks ago
> glyr  orphan   0 weeks ago
> gmpc  orphan   0 weeks ago
> gnome-code-assistance elad, orphan 0 weeks ago
> gnome-documents   anujmore, cosimoc, gnome-sig,0 weeks ago
>orphan
> 

[Bug 1893136] RFE - build a perl-Future package for EPEL8

[bugzilla]

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

Steve Traylen  changed:

   What|Removed |Added

 Blocks||1900710





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1900710
[Bug 1900710] RFE - build perl-Object-Remote for epel 8
-- 
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

[Bug 1822398] Request for perl-Net-OpenSSH for EPEL8

[bugzilla]

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

Steve Traylen  changed:

   What|Removed |Added

 Depends On||1900710





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1900710
[Bug 1900710] RFE - build perl-Object-Remote for epel 8
-- 
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

[Bug 1900710] RFE - build perl-Object-Remote for epel 8

[bugzilla]

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

Steve Traylen  changed:

   What|Removed |Added

 Blocks||1781754, 1822398
 Depends On||1893136
   Doc Type|--- |If docs needed, set a value





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1781754
[Bug 1781754] Co-maintainer request (to maintain EPEL8 branch)
https://bugzilla.redhat.com/show_bug.cgi?id=1822398
[Bug 1822398] Request for perl-Net-OpenSSH for EPEL8
https://bugzilla.redhat.com/show_bug.cgi?id=1893136
[Bug 1893136] RFE - build a perl-Future package for EPEL8
-- 
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

[Bug 1781754] Co-maintainer request (to maintain EPEL8 branch)

[bugzilla]

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

Steve Traylen  changed:

   What|Removed |Added

 Depends On||1900710





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1900710
[Bug 1900710] RFE - build perl-Object-Remote for epel 8
-- 
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

[Bug 1900710] New: RFE - build perl-Object-Remote for epel 8

[bugzilla]

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

Bug ID: 1900710
   Summary: RFE - build perl-Object-Remote for epel 8
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Object-Remote
  Assignee: jples...@redhat.com
  Reporter: steve.tray...@cern.ch
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Hi,
Please can perl-Object-Remote be built and released for EPEL8.

I've confirmed that the package can be built and installed if
perl-Future was available which is currently not the case.


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

[Bug 1821881] CVE-2013-7488 perl-Convert-ASN1: allows remote attackers to cause an infinite loop via unexpected input [fedora-all]

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Convert-ASN1-0.27-21.f
   ||c34




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

OGRE soname bump on rawhide Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Sérgio Basto]

Sorry , 
I updated ogre in rawhide to ogre-1.12.6 ( the PR 
https://src.fedoraproject.org/rpms/ogre/pull-request/1 was ready 5
months ago ) 

I did a wrong repoquery. I though ogre didn't have any dependency. I
did a query that only query rpmfusion repos, instead query fedora
repos 

I hope does not make much trouble , so we need rebuild [1] based on
query [2] .


[1]
SkyX-0:0.4-28.fc33.src
cegui-0:0.8.7-20.fc33.src
fawkes-0:1.3.1-0.5.4923a6c.fc34.src
funguloids-0:1.06-36.fc33.src
gazebo-0:10.1.0-12.fc34.src
meshmagick-0:0.6.0-42.svn2898.fc32.src
mygui-0:3.2.2-13.fc32.src
ogre-pagedgeometry-1:1.1.4-14.20131226hg3ad14141c027.fc32.src
shiny-0:0.3-29.git411ac43.fc33.src
sumwars-0:0.5.8-23.fc34.src

[2]
dnf repoquery --disablerepo='*' --enablerepo={rpmfusion-{non,}free-
,}rawhide-source --arch=src  --whatrequires ogre-devel 

On Mon, 2020-11-23 at 12:08 +, Sérgio Basto wrote:
> Yesterday,  I took ogre
> 
> I plan update ogre to ogre-1.12.6 and later update to ogre-1.12.9 on
> F33 
> 
> 
> On Mon, 2020-11-23 at 10:30 +0100, Miro Hrončok wrote:
> > The following packages are orphaned and will be retired when they
> > are orphaned for six weeks, unless someone adopts them. If you know
> > for sure
> > that the package should be retired, please do so now with a proper
> > reason:
> > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> > 
> > Note: If you received this mail directly you (co)maintain one of
> > the
> > affected
> > packages or a package that depends on one. Please adopt the
> > affected
> > package or
> > retire your depending package to avoid broken dependencies,
> > otherwise
> > your
> > package will be retired when the affected package gets retired.
> > 
> > Request package ownership via the *Take* button in he left column
> > on
> > https://src.fedoraproject.org/rpms/
> > 
> > Full report available at:
> > https://churchyard.fedorapeople.org/orphans-2020-11-23.txt
> > grep it for your FAS username and follow the dependency chain.
> > 
> > For human readable dependency chains, see 
> > https://packager.fedorainfracloud.org/
> > For all orphaned packages, see 
> > https://packager.fedorainfracloud.org/orphan
> > 
> >  Package  (co)maintainers  
> >  S
> > tatus Change
> > ===
> > ==
> > ===
> > Pencil2D  lbazan,
> > orphan   0
> > weeks ago
> > RxCpp orphan   
> > 0
> > weeks ago
> > ansible-collection
> > -community- orphan   3
> > weeks ago
> > general
> > apivizlef,
> > orphan  0
> > weeks ago
> > apper kde-sig, orphan,
> > rhughes 0
> > weeks ago
> > bfast orphan   
> > 0
> > weeks ago
> > biblesync cicku,
> > orphan0
> > weeks ago
> > bifcl orphan   
> > 0
> > weeks ago
> > bmon  orphan   
> > 0
> > weeks ago
> > celt071   orphan   
> > 4
> > weeks ago
> > colorhug-
> > client   orphan   1
> > weeks ago
> > compat-guile18jskarvad, mlichvar,
> > orphan,  3
> > weeks ago
> >tkorbar
> > cook  orphan   
> > 0
> > weeks ago
> > coolreaderorphan   
> > 0
> > weeks ago
> > couchdb   orphan   
> > 0
> > weeks ago
> > cpulimit  orphan   
> > 0
> > weeks ago
> > cros-guest-
> > tools  orphan   1
> > weeks ago
> > dc3dd maxamillion,
> > orphan  0
> > weeks ago
> > dep   go-sig,
> > orphan   0
> > weeks ago
> > discord-
> > irc   orphan   3
> > weeks ago
> > dnscaporphan   
> > 4
> > weeks ago
> > dnsjava   orphan   
> > 0
> > weeks ago
> > dumb-
> > init orphan   0
> > weeks ago
> > dynaplugz orphan   
> > 0
> > weeks ago
> > edb   orphan   
> > 0
> > weeks ago
> > elasticdump   orphan   
> > 3
> > weeks ago
> > electric  blackfile,
> > orphan0
> > weeks ago
> > electrum  orphan   
> > 4
> > weeks 

Nonresponsive maintainer for easytag

[Matti Pulkkinen]

Following along with the steps at [1] I've opened a nonresponsive 
maintainer bug for easytag [2]. Does anyone have contact with amigadave? 
Other than the bug report I've just opened, there are three other ones 
that haven't received a response, one of which is also mine [3][4][5].




[1] 
https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1900695
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1791511
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1893457
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1727568

--
Terveisin / Regards,
Matti Pulkkinen
___
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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Gwyn Ciesla via devel]

Took libebur128, sgpio, compat-guile18, python-dijitso.


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Monday, November 23, 2020 3:30 AM, Miro Hrončok  wrote:

> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 

> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package 
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
> 

> Request package ownership via the Take button in he left column on
> https://src.fedoraproject.org/rpms/
> 

> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-11-23.txt
> grep it for your FAS username and follow the dependency chain.
> 

> For human readable dependency chains, see 
> https://packager.fedorainfracloud.org/
> For all orphaned packages, see https://packager.fedorainfracloud.org/orphan
> 

> Package (co)maintainers Status Change
> 

> ===
> 

> Pencil2D lbazan, orphan 0 weeks ago
> RxCpp orphan 0 weeks ago
> ansible-collection-community- orphan 3 weeks ago
> general
> apiviz lef, orphan 0 weeks ago
> apper kde-sig, orphan, rhughes 0 weeks ago
> bfast orphan 0 weeks ago
> biblesync cicku, orphan 0 weeks ago
> bifcl orphan 0 weeks ago
> bmon orphan 0 weeks ago
> celt071 orphan 4 weeks ago
> colorhug-client orphan 1 weeks ago
> compat-guile18 jskarvad, mlichvar, orphan, 3 weeks ago
> tkorbar
> cook orphan 0 weeks ago
> coolreader orphan 0 weeks ago
> couchdb orphan 0 weeks ago
> cpulimit orphan 0 weeks ago
> cros-guest-tools orphan 1 weeks ago
> dc3dd maxamillion, orphan 0 weeks ago
> dep go-sig, orphan 0 weeks ago
> discord-irc orphan 3 weeks ago
> dnscap orphan 4 weeks ago
> dnsjava orphan 0 weeks ago
> dumb-init orphan 0 weeks ago
> dynaplugz orphan 0 weeks ago
> edb orphan 0 weeks ago
> elasticdump orphan 3 weeks ago
> electric blackfile, orphan 0 weeks ago
> electrum orphan 4 weeks ago
> erlang-corba orphan 0 weeks ago
> erlang-lager bowlofeggs, orphan 0 weeks ago
> eyesight cicku, orphan, plfiorini 0 weeks ago
> fedora-developer-portal orphan 2 weeks ago
> fifechan orphan 0 weeks ago
> fillets-ng orphan, thias 0 weeks ago
> flacon ignatenkobrain, orphan 0 weeks ago
> fmpp orphan 0 weeks ago
> fossil orphan 0 weeks ago
> freetiger orphan 0 weeks ago
> gaupol mmraka, orphan 0 weeks ago
> ghc-pipes-safe orphan 3 weeks ago
> glyr orphan 0 weeks ago
> gmpc orphan 0 weeks ago
> gnome-code-assistance elad, orphan 0 weeks ago
> gnome-documents anujmore, cosimoc, gnome-sig, 0 weeks ago
> orphan
> golang-contrib-opencensus- go-sig, orphan 0 weeks ago
> exporter-ocagent
> golang-github-casbin go-sig, orphan 0 weeks ago
> golang-github-cenkalti-backoff go-sig, jchaloup, orphan 0 weeks ago
> golang-github-cespare-xxhash go-sig, orphan 0 weeks ago
> golang-github-henvic-httpretty orphan 0 weeks ago
> golang-github-paulbellamy- go-sig, orphan 0 weeks ago
> ratecounter
> golang-k8s-kubernetes go-sig, orphan 0 weeks ago
> goobook halfie, helloworld1, orphan 0 weeks ago
> gplugin orphan 0 weeks ago
> gridftp-ifce orphan 0 weeks ago
> gtatool orphan 3 weeks ago
> hsakmt orphan 0 weeks ago
> hsqldb1 lef, orphan 3 weeks ago
> icemon orphan 0 weeks ago
> innoextract moceap, orphan 0 weeks ago
> java-comment-preprocessor hhorak, orphan, panovotn, 0 weeks ago
> praiskup
> jaxodraw orphan 0 weeks ago
> jblas orphan 0 weeks ago
> jboss-servlet-2.5-api dmoluguw, orphan 0 weeks ago
> jfontchooser orphan 0 weeks ago
> jgraphx jerboaa, orphan 1 weeks ago
> jgroups gil, goldmann, lef, orphan 0 weeks ago
> jing-trang orphan 0 weeks ago
> jnettop orphan 0 weeks ago
> js-html5shiv orphan 0 weeks ago
> js-jquery-file-upload orphan 0 weeks ago
> js-respond orphan 0 weeks ago
> jsl orphan, scenek 0 weeks ago
> jsonp lef, orphan 3 weeks ago
> kawa orphan 0 weeks ago
> klatexformula orphan 0 weeks ago
> koschei mizdebsk, orphan 0 weeks ago
> legendsbrowser orphan 3 weeks ago
> libad9361 orphan 0 weeks ago
> libbind orphan 4 weeks ago
> libbtbb orphan 0 weeks ago
> libebur128 orphan 0 weeks ago
> libemu orphan 0 weeks ago
> libgcal orphan 0 weeks ago
> libjson-rpc-cpp orphan, slaanesh 0 weeks ago
> libpri itamarjp, orphan 0 weeks 

[Bug 1900678] New: perl-Convert-Binary-C-0.84 is available

[bugzilla]

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

Bug ID: 1900678
   Summary: perl-Convert-Binary-C-0.84 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Convert-Binary-C
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: al...@users.sourceforge.net, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 0.84
Current version/release in rawhide: 0.83-1.fc34
URL: http://search.cpan.org/dist/Convert-Binary-C/

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


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


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


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


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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Richard Shaw]

I took soundconverter

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

GitLab AMA Topic Follow Up: Namespace & Issue Tracking

[Aoife Moloney]

# GitLab AMA Session Topic - Namespace & Issue Tracking

Hi everyone,

Thanks again for your involvement in the GitLab AMA session on IRC in
September. This email discussion thread is on Namespace & Issue
Tracking. I have pulled the relevant questions and answers from the
original hackmd doc into one email and if you would like to discuss
this topic specifically, here might be a good place to do so so your
conversations don't go down a 'rabbit hole' :)

Here are some links to resources as well:
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
* AMA Blog post
https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
* Here is this email in hackmd if you wish to view it there:
https://hackmd.io/oZrDwbSeSWO-l_X65A1ndg?view

## Namespace & Issue Tracking
- Question: Currently dist-git in Fedora has several namespaces: rpms,
modules, containers, tests... All namespaces but the ``tests``
namespace have their issue tracker in bugzilla. Would this work in
gitlab? Can we selectively enable/disable issue tracking per namespace
for the entire instance? (ie: w/o giving the possibility to ``owner``
or ``maintainer`` to toggle that setting.)
- Answer: It may need to be checked again, but it appears you can
turn on/off the issue tracker at the project level.

- Question: Currently dist-git in Fedora has several namespaces: rpms,
modules, containers, tests... All namespaces but the ``tests``
namespace have their issue tracker in bugzilla. Would this work in
gitlab? Can we selectively enable/disable issue tracking per namespace
for the entire instance? (ie: w/o giving the possibility to ``owner``
or ``maintainer`` to toggle that setting.)
- Answer: You can turn the GitLab issue tracker on and off by
project. See 
https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions
Namespaces map to “group” in GitLab. Here’s more info about them:
https://docs.gitlab.com/ee/api/namespaces.html

- Question: Fedora, as far as I understand, still plan on using
bugzilla as issue tracker. Currently default assignee and the CC are
gathered using the ``main admin`` (ie: the ``owner`` for GitLab iiuc),
the other maintainers (who did not ``unwatch issues`` in the project -
mechanism for them to opt-out of being in the CC list) and the people
having enabled ``Issue watching`` for the project (mechanism for them
to opt-in into being in the CC list). Would this work in a GitLab
world?
- Answer: There are a number of options related to that.  For one,
users can control their notifications globally and by name space in a
fine grained way (see GitLab Notification Emails).

- Question: Fedora is part of GitLab’s Open Source program and we have
a migration tracker issue that we are using to keep track of feature
requests, bugs, etc that are important to Fedora. The Fedora migration
team has been working with us at GitLab to maintain that and community
members can add relevant issues there so we can track them. It’s also
helpful for our product managers to hear about why particular issues
are important for the Fedora use case, and to have upvotes, so doing
that will help! Where can you submit requests/bugs/report issues?
- Answer:
Fedora Migration Tracker:
https://gitlab.com/gitlab-org/gitlab/-/issues/217350
Feature template:
https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal
Bug template:
https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Bug


Please do review the original questions doc in case I have missed any
that relate to namespace and issue tracking and thank you again for
your engagement with these emails! The next email topic will be on
'Branches'.



Have a good week!
Aoife

-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

GitLab AMA Topic Follow Up: Namespace & Issue Tracking

[Aoife Moloney]

# GitLab AMA Session Topic - Namespace & Issue Tracking

Hi everyone,

Thanks again for your involvement in the GitLab AMA session on IRC in
September. This email discussion thread is on Namespace & Issue
Tracking. I have pulled the relevant questions and answers from the
original hackmd doc into one email and if you would like to discuss
this topic specifically, here might be a good place to do so so your
conversations don't go down a 'rabbit hole' :)

Here are some links to resources as well:
* Questions and Answers hackmd link https://hackmd.io/RW8HahOeR7OJPON1dwuo3w
* Chat log from session
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-09-10/ama_session_with_gitlab.2020-09-10-13.31.log.html
* AMA Blog post
https://communityblog.fedoraproject.org/gitlab-ama-follow-up/#more-9346
* Here is this email in hackmd if you wish to view it there:
https://hackmd.io/oZrDwbSeSWO-l_X65A1ndg?view

## Namespace & Issue Tracking
- Question: Currently dist-git in Fedora has several namespaces: rpms,
modules, containers, tests... All namespaces but the ``tests``
namespace have their issue tracker in bugzilla. Would this work in
gitlab? Can we selectively enable/disable issue tracking per namespace
for the entire instance? (ie: w/o giving the possibility to ``owner``
or ``maintainer`` to toggle that setting.)
- Answer: It may need to be checked again, but it appears you can
turn on/off the issue tracker at the project level.

- Question: Currently dist-git in Fedora has several namespaces: rpms,
modules, containers, tests... All namespaces but the ``tests``
namespace have their issue tracker in bugzilla. Would this work in
gitlab? Can we selectively enable/disable issue tracking per namespace
for the entire instance? (ie: w/o giving the possibility to ``owner``
or ``maintainer`` to toggle that setting.)
- Answer: You can turn the GitLab issue tracker on and off by
project. See 
https://docs.gitlab.com/ee/user/project/settings/#sharing-and-permissions
Namespaces map to “group” in GitLab. Here’s more info about them:
https://docs.gitlab.com/ee/api/namespaces.html

- Question: Fedora, as far as I understand, still plan on using
bugzilla as issue tracker. Currently default assignee and the CC are
gathered using the ``main admin`` (ie: the ``owner`` for GitLab iiuc),
the other maintainers (who did not ``unwatch issues`` in the project -
mechanism for them to opt-out of being in the CC list) and the people
having enabled ``Issue watching`` for the project (mechanism for them
to opt-in into being in the CC list). Would this work in a GitLab
world?
- Answer: There are a number of options related to that.  For one,
users can control their notifications globally and by name space in a
fine grained way (see GitLab Notification Emails).

- Question: Fedora is part of GitLab’s Open Source program and we have
a migration tracker issue that we are using to keep track of feature
requests, bugs, etc that are important to Fedora. The Fedora migration
team has been working with us at GitLab to maintain that and community
members can add relevant issues there so we can track them. It’s also
helpful for our product managers to hear about why particular issues
are important for the Fedora use case, and to have upvotes, so doing
that will help! Where can you submit requests/bugs/report issues?
- Answer:
Fedora Migration Tracker:
https://gitlab.com/gitlab-org/gitlab/-/issues/217350
Feature template:
https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20proposal
Bug template:
https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Bug


Please do review the original questions doc in case I have missed any
that relate to namespace and issue tracking and thank you again for
your engagement with these emails! The next email topic will be on
'Branches'.



Have a good week!
Aoife

-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-11-23.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains, see https://packager.fedorainfracloud.org/
For all orphaned packages, see https://packager.fedorainfracloud.org/orphan

Package  (co)maintainers   Status Change

Pencil2D  lbazan, orphan   0 weeks ago
RxCpp orphan   0 weeks ago
ansible-collection-community- orphan   3 weeks ago
general
apivizlef, orphan  0 weeks ago
apper kde-sig, orphan, rhughes 0 weeks ago
bfast orphan   0 weeks ago
biblesync cicku, orphan0 weeks ago
bifcl orphan   0 weeks ago
bmon  orphan   0 weeks ago
celt071   orphan   4 weeks ago
colorhug-client   orphan   1 weeks ago
compat-guile18jskarvad, mlichvar, orphan,  3 weeks ago
  tkorbar
cook  orphan   0 weeks ago
coolreaderorphan   0 weeks ago
couchdb   orphan   0 weeks ago
cpulimit  orphan   0 weeks ago
cros-guest-tools  orphan   1 weeks ago
dc3dd maxamillion, orphan  0 weeks ago
dep   go-sig, orphan   0 weeks ago
discord-irc   orphan   3 weeks ago
dnscaporphan   4 weeks ago
dnsjava   orphan   0 weeks ago
dumb-init orphan   0 weeks ago
dynaplugz orphan   0 weeks ago
edb   orphan   0 weeks ago
elasticdump   orphan   3 weeks ago
electric  blackfile, orphan0 weeks ago
electrum  orphan   4 weeks ago
erlang-corba  orphan   0 weeks ago
erlang-lager  bowlofeggs, orphan   0 weeks ago
eyesight  cicku, orphan, plfiorini 0 weeks ago
fedora-developer-portal   orphan   2 weeks ago
fifechan  orphan   0 weeks ago
fillets-ngorphan, thias0 weeks ago
flaconignatenkobrain, orphan   0 weeks ago
fmpp  orphan   0 weeks ago
fossilorphan   0 weeks ago
freetiger orphan   0 weeks ago
gaupolmmraka, orphan   0 weeks ago
ghc-pipes-safeorphan   3 weeks ago
glyr  orphan   0 weeks ago
gmpc  orphan   0 weeks ago
gnome-code-assistance elad, orphan 0 weeks ago
gnome-documents   anujmore, cosimoc, gnome-sig,0 weeks ago
  orphan
golang-contrib-opencensus-go-sig, orphan   0 weeks ago
exporter-ocagent
golang-github-casbin  go-sig, orphan   0 weeks ago
golang-github-cenkalti-backoffgo-sig, jchaloup, orphan 0 weeks ago

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Sérgio Basto]

Yesterday,  I took ogre

I plan update ogre to ogre-1.12.6 and later update to ogre-1.12.9 on
F33 


On Mon, 2020-11-23 at 10:30 +0100, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know
> for sure
> that the package should be retired, please do so now with a proper
> reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise
> your
> package will be retired when the affected package gets retired.
> 
> Request package ownership via the *Take* button in he left column on
> https://src.fedoraproject.org/rpms/
> 
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2020-11-23.txt
> grep it for your FAS username and follow the dependency chain.
> 
> For human readable dependency chains, see 
> https://packager.fedorainfracloud.org/
> For all orphaned packages, see 
> https://packager.fedorainfracloud.org/orphan
> 
>  Package  (co)maintainers   S
> tatus Change
> =
> ===
> Pencil2D  lbazan, orphan   0
> weeks ago
> RxCpp orphan   0
> weeks ago
> ansible-collection-community- orphan   3
> weeks ago
> general
> apivizlef, orphan  0
> weeks ago
> apper kde-sig, orphan, rhughes 0
> weeks ago
> bfast orphan   0
> weeks ago
> biblesync cicku, orphan0
> weeks ago
> bifcl orphan   0
> weeks ago
> bmon  orphan   0
> weeks ago
> celt071   orphan   4
> weeks ago
> colorhug-client   orphan   1
> weeks ago
> compat-guile18jskarvad, mlichvar, orphan,  3
> weeks ago
>tkorbar
> cook  orphan   0
> weeks ago
> coolreaderorphan   0
> weeks ago
> couchdb   orphan   0
> weeks ago
> cpulimit  orphan   0
> weeks ago
> cros-guest-tools  orphan   1
> weeks ago
> dc3dd maxamillion, orphan  0
> weeks ago
> dep   go-sig, orphan   0
> weeks ago
> discord-irc   orphan   3
> weeks ago
> dnscaporphan   4
> weeks ago
> dnsjava   orphan   0
> weeks ago
> dumb-init orphan   0
> weeks ago
> dynaplugz orphan   0
> weeks ago
> edb   orphan   0
> weeks ago
> elasticdump   orphan   3
> weeks ago
> electric  blackfile, orphan0
> weeks ago
> electrum  orphan   4
> weeks ago
> erlang-corba  orphan   0
> weeks ago
> erlang-lager  bowlofeggs, orphan   0
> weeks ago
> eyesight  cicku, orphan, plfiorini 0
> weeks ago
> fedora-developer-portal   orphan   2
> weeks ago
> fifechan  orphan   0
> weeks ago
> fillets-ngorphan, thias0
> weeks ago
> flaconignatenkobrain, orphan   0
> weeks ago
> fmpp  orphan   0
> weeks ago
> fossilorphan   0
> weeks ago
> freetiger orphan   0
> weeks ago
> gaupolmmraka, orphan   0
> weeks ago
> ghc-pipes-safeorphan   3
> weeks ago
> glyr  orphan   0
> weeks ago
> gmpc  orphan   0
> weeks ago
> gnome-code-assistance elad, orphan 0
> 

Re: Fedora 34 Change: GNU Toolchain update (gcc 11, glibc 2.33) (System-Wide Change)

[Florian Weimer]

* Fabio Valentini:

> Are there plans to fix the glibc faccessat2 issues with older
> systemd-nspawn and docker?

I'm trying to gather the status on this; I've been out of touch for a
couple of days.

I do not feel comfortable to ship a Fedora-only patch for this.  My hope
is that we can work out something with all the projects involved.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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

Re: Fedora 34 Change: GNU Toolchain update (gcc 11, glibc 2.33) (System-Wide Change)

[Fabio Valentini]

On Mon, Nov 23, 2020 at 11:51 AM Florian Weimer  wrote:
>
> * Simo Sorce:
>
> > On Fri, 2020-11-20 at 11:26 -0500, Ben Cotton wrote:
> >> https://fedoraproject.org/wiki/Changes/GNUToolchain
> >>
> >> == Summary ==
> >> Switch the Fedora 33 GNU Toolchain to gcc 11, binutils 2.35, and glibc 
> >> 2.33.
> >
> > Hi Ben, shouldn't this ^^ be Fedora 34 ?
>
> I fixed it on the wiki, and also the wrong glibc version/release date.

Are there plans to fix the glibc faccessat2 issues with older
systemd-nspawn and docker?
It would be a shame if fedora 34 containers wouldn't be able to run
correctly in most circumstances.

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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Antonio T. sagitter]

Paulo, we're in trouble with 'scala' (and jacop).
I don't know how it's built ... i have no experience with Java/Maven 
packages.


On 23/11/20 10:30, Miro Hrončok wrote:

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for 
sure

that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the 
affected
packages or a package that depends on one. Please adopt the affected 
package or

retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-11-23.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains, see 
https://packager.fedorainfracloud.org/

For all orphaned packages, see https://packager.fedorainfracloud.org/orphan

     Package  (co)maintainers   
Status Change
 


sagitter: scala



--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


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

CPE Weekly: 2020-11-22

[Aoife Moloney]

Hi Everyone,

Below is this week's CPE weekly for week ending 2020-11-22 for both
Fedora & CentOS, and if you want to visit the hackmd link
https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view you can then use the
header bar on your left to skip to Fedora or CentOS updates that
interest you.


## General Project Updates
Final project submission date for consideration in Q1 is Friday 27th
November. If you have an initiative that may take weeks/months and
multiple people to work on and want to request it to CPE, please
follow the steps outlined in our initiatives repo and create your
issue before 27th November https://pagure.io/cpe/initiatives-proposal
Our updated initative timetable can be viewed here for 2021
https://docs.fedoraproject.org/en-US/cpe/time_tables/


Below are the projects the CPE team are currently working on for the
months of October, November & December:
* CentOS Stream Phase 4 - Build system services
* Noggin Phase 4 - Data Migration of Fedora & CentOS Accounts, Community testing
* OSBS for aarch64 - this will begin in November
* Fedora Messaging Schemas - this work is continuing from Q3 and is
being worked on part-time

### Misc
 GitLab
New GitLab topic sent to devel-annou...@lists.fedoraproject.org &
centos-de...@centos.org on Message Bus is out. See email in hackmd
here
https://hackmd.io/oZrDwbSeSWO-l_X65A1ndg?view

## Project Updates
*The below updates are pulled directly from our CPE team call we have
every week.*
### Fedora

### Staging Environment
* Completed - any issues you find please report them in fedora infra
https://pagure.io/fedora-infrastructure/issues

### Noggin/AAA
* Testing team owned apps in staging with Noggin
* We will be requesting community member testing  before December so
keep an eye out for an announcement!
* The teams kanban board where they track their work can be found here
https://github.com/orgs/fedora-infra/projects/6
* And we have a project tracker available to be viewed here
https://github.com/fedora-infra/aaa-tracker

### OSBS for aarch64
* Basic OKD 3.11 working on aarm64 with F31
* Working on repeating that install with F33
* Next step will be to

### Fedora Messaging Schemas
* This project is worked on on a part time basis as we are
prioritizing completing Noggin first before fully committing to its
completion
* There is a list of applications that require messaging schemas can
be found here https://hackmd.io/@nilsph/H1i8CAbkP/edit
* There is a readme which contains documentation on messaging schemas,
a cookie-cutter template to create the schema and a definition of Done
for writing a schemas
https://github.com/fedora-infra/fedora-messaging-schemas-issues
* The board they are working from can be viewed here
https://github.com/orgs/fedora-infra/projects/7


## CentOS Updates

### CentOS
* CentOS 6 is EOL 30th November
* CFP for FOSDEM Dojo - https://wiki.centos.org/Events/Dojo/FOSDEM2021
* Updated CentOS CI Openshift staging cluster to latest 4.6.4, Waiting
for stable release in the 4.6 branch before rolling out to production.
* CentOS 7.9.2009 is released! (for x86_64, i386, ppc64, ppc64le,
armhfp and aarch64 architectures)
* Lot of work done for Noggin/AAA



### CentOS Stream
* Use centos-stream-release package to convert from CentOS 6 to CentOS
Stream before 30th November
* Working on integrating ODCS in Stream
* Curating out t_functional suite
https://github.com/centos/sig-core-t_functional
* Refining our testing for finding issues at distro-level


## Team Info
### CPE Product Owner Office Hours
IRC office hours are now once per month.Below are the logs from the
most recent meetings and dates for the next ones.
 #fedora-meeting-1
* Next Meeting: 2020-12-17 @ 1300 UTC on #fedora-meeting-1
 #centos-meeting
* Next Meeting: 2020-12-15 @ 1500 UTC on #centos-meeting


## Background:
The Community Platform Engineering group, or CPE for short, is the Red
Hat team combining IT and release engineering from Fedora and CentOS.
Our goal is to keep core servers and services running and maintained,
build releases, and other strategic tasks that need more dedicated
time than volunteers can give.


See our wiki page here for more
information:https://docs.fedoraproject.org/en-US/cpe/



As always, feedback is welcome, and we will continue to look at ways
to improve the delivery and readability of this weekly report.


Have a great week!

Aoife


Source: https://hackmd.io/8iV7PilARSG68Tqv8CzKOQ?view


-- 
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
___
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

Re: Fedora 34 Change: GNU Toolchain update (gcc 11, glibc 2.33) (System-Wide Change)

[Florian Weimer]

* Simo Sorce:

> On Fri, 2020-11-20 at 11:26 -0500, Ben Cotton wrote:
>> https://fedoraproject.org/wiki/Changes/GNUToolchain
>> 
>> == Summary ==
>> Switch the Fedora 33 GNU Toolchain to gcc 11, binutils 2.35, and glibc 2.33.
>
> Hi Ben, shouldn't this ^^ be Fedora 34 ?

I fixed it on the wiki, and also the wrong glibc version/release date.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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

Re: Disabling Fedora 30 chroots in Copr

[Alexander Ploumistos]

On Mon, Nov 23, 2020 at 11:31 AM Jakub Kadlcik  wrote:
>
> Ah, so you meant the F28 and F29 chroots listed here in the build details, 
> e.g.
>
> https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/build/869545/

Yes, that's what I was talking about.


> That is as expected. Possibly we can improve our deletion script to
> hide/remove them as well but it is not done yet. The important thing
> (from our perspective) is that there is no F28 and F29 data on the
> backend
>
> https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/repositories/
> https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/repositories/
>
> and therefore we could reclaim its disk space.

OK then, thanks for the clarification.

Best regards,
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

Re: Fedora 34 Change proposal: Remove and deprecate nscd in favour of sssd and systemd-resolved (Self-Contained Change)

[Florian Weimer]

* Marius Schwarz:

>  It not only caches names, it also RANDOMIZES the requests to the dns
> servers configured, increasing the privacy of ones internet journey.

> That it does it, was the reason i tried it out at home  ;)

Let me repeat then, less politely: It does not do any such thing.  You
have been misled.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
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

Fedora-Cloud-31-20201123.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 7/7 (x86_64), 7/7 (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

Re: Disabling Fedora 30 chroots in Copr

[Jakub Kadlcik]

Ah, so you meant the F28 and F29 chroots listed here in the build details, e.g.

https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/build/869545/

That is as expected. Possibly we can improve our deletion script to
hide/remove them as well but it is not done yet. The important thing
(from our perspective) is that there is no F28 and F29 data on the
backend

https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/repositories/
https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/repositories/

and therefore we could reclaim its disk space.


Jakub

On Mon, Nov 23, 2020 at 10:58 AM Alexander Ploumistos
 wrote:
>
> Hello again,
>
> Perhaps I'm the one who's misunderstood. Is the fact that F28 and F29 builds 
> are still around unrelated to which chroots are actually there?
> ___
> 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
___
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

Re: Sundials-5.5.0+PETSc-3.14.1 updates on Rawhide

[Antonio T. sagitter]

I have not the permissions for pushing these packages.
Please, push them all related to the tag f34-build-side-34403


--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0x29FBC85D7A51CC2F
GPG key server: https://keys.gnupg.net/


OpenPGP_0x29FBC85D7A51CC2F.asc
Description: application/pgp-keys


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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Artur Frenszek-Iwicki]

I took over cpulimit.
___
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

Re: Disabling Fedora 30 chroots in Copr

[Alexander Ploumistos]

Hello again,

Perhaps I'm the one who's misunderstood. Is the fact that F28 and F29
builds are still around unrelated to which chroots are actually there?
___
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

Re: Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Sandro Mani]

I've taken


mingw-speex


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

Re: Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)

[edmond pilon]

I  have  installed pipewire-pulseaudio,  pipewire-libjack  pipewire-alsa ( 
pipewire 3.16  rawhide ).
Pulseaudio is removed   but nevertheless i have no issue actually. Sounds and 
software (pavucontrol ..etc) are working.
Only  one of my  mixers (plasma-pa) is  removed because of a pulseaudio 
dependency and needs to be rebuild.
 Sorry for my english.
___
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

Orphaned packages looking for new maintainers (hundreds of freshly orphaned F33FTBFS)

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-11-23.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains, see https://packager.fedorainfracloud.org/
For all orphaned packages, see https://packager.fedorainfracloud.org/orphan

Package  (co)maintainers   Status Change

Pencil2D  lbazan, orphan   0 weeks ago
RxCpp orphan   0 weeks ago
ansible-collection-community- orphan   3 weeks ago
general
apivizlef, orphan  0 weeks ago
apper kde-sig, orphan, rhughes 0 weeks ago
bfast orphan   0 weeks ago
biblesync cicku, orphan0 weeks ago
bifcl orphan   0 weeks ago
bmon  orphan   0 weeks ago
celt071   orphan   4 weeks ago
colorhug-client   orphan   1 weeks ago
compat-guile18jskarvad, mlichvar, orphan,  3 weeks ago
  tkorbar
cook  orphan   0 weeks ago
coolreaderorphan   0 weeks ago
couchdb   orphan   0 weeks ago
cpulimit  orphan   0 weeks ago
cros-guest-tools  orphan   1 weeks ago
dc3dd maxamillion, orphan  0 weeks ago
dep   go-sig, orphan   0 weeks ago
discord-irc   orphan   3 weeks ago
dnscaporphan   4 weeks ago
dnsjava   orphan   0 weeks ago
dumb-init orphan   0 weeks ago
dynaplugz orphan   0 weeks ago
edb   orphan   0 weeks ago
elasticdump   orphan   3 weeks ago
electric  blackfile, orphan0 weeks ago
electrum  orphan   4 weeks ago
erlang-corba  orphan   0 weeks ago
erlang-lager  bowlofeggs, orphan   0 weeks ago
eyesight  cicku, orphan, plfiorini 0 weeks ago
fedora-developer-portal   orphan   2 weeks ago
fifechan  orphan   0 weeks ago
fillets-ngorphan, thias0 weeks ago
flaconignatenkobrain, orphan   0 weeks ago
fmpp  orphan   0 weeks ago
fossilorphan   0 weeks ago
freetiger orphan   0 weeks ago
gaupolmmraka, orphan   0 weeks ago
ghc-pipes-safeorphan   3 weeks ago
glyr  orphan   0 weeks ago
gmpc  orphan   0 weeks ago
gnome-code-assistance elad, orphan 0 weeks ago
gnome-documents   anujmore, cosimoc, gnome-sig,0 weeks ago
  orphan
golang-contrib-opencensus-go-sig, orphan   0 weeks ago
exporter-ocagent
golang-github-casbin  go-sig, orphan   0 weeks ago
golang-github-cenkalti-backoffgo-sig, jchaloup, orphan 0 weeks ago

Re: Disabling Fedora 30 chroots in Copr

[Jakub Kadlcik]

But I can't see any data on the backend, that are older than F30 for
those respective projects:

https://download.copr.fedorainfracloud.org/results/alexpl/molsketch/
https://download.copr.fedorainfracloud.org/results/alexpl/scidavis/

Is that what you mean by

> I noticed that some of my projects still have chroots for even older
> releases, e.g. F28, F29 without the option to remove them.

Or did I misunderstood?


Thank you for the feedback,
Jakub

On Mon, Nov 23, 2020 at 10:04 AM Alexander Ploumistos
 wrote:
>
> On Mon, Nov 23, 2020 at 9:54 AM Jakub Kadlcik  wrote:
> >
> > Hello Alexander,
> > what do those chroots say in their "Remaining time" column, please?
>
> They are not listed at all, see these two:
> https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/repositories/
> https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/repositories/
> ___
> 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
___
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

Re: Disabling Fedora 30 chroots in Copr

[Alexander Ploumistos]

On Mon, Nov 23, 2020 at 9:54 AM Jakub Kadlcik  wrote:
>
> Hello Alexander,
> what do those chroots say in their "Remaining time" column, please?

They are not listed at all, see these two:
https://copr.fedorainfracloud.org/coprs/alexpl/molsketch/repositories/
https://copr.fedorainfracloud.org/coprs/alexpl/scidavis/repositories/
___
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

Re: Disabling Fedora 30 chroots in Copr

[Jakub Kadlcik]

Hello Alexander,
what do those chroots say in their "Remaining time" column, please?


Jakub

On Mon, Nov 23, 2020 at 8:34 AM Alexander Ploumistos
 wrote:
>
> Hello Jakub,
>
> I noticed that some of my projects still have chroots for even older
> releases, e.g. F28, F29 without the option to remove them. In another
> instance, only a specific F30 arch shows up among the chroots to be
> removed or extended, while the others architectures are not picked up.
> Is there something I can do to remove them, other than deleting the
> entire build along with every other chroot?
>
> Best regards,
> 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
___
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

rubygem-ronn being replaced by rubygem-ronn-ng

[Vít Ondruch]

Hi,

I'd like to announce, that rubygem-ronn, which have not seen release in 
ages, was retired in Fedora and it is replaced by rubygem-ronn-ng. If 
you are using Ronn (maintainers of affected packages in BCC), please 
check your package if it is not FTBFS by a chance.


Sorry for not announcing it prior landing this change. I was so excited 
to retire the unmaintained Ronn that I forgot I should communicate this 
in advance.



Vít



OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


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