Fedora-Cloud-33-20201121.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-20201120.0):

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

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

[Bug 1900029] perl-Moo-2.004003 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Moo-2.004002 is|perl-Moo-2.004003 is
   |available   |available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 2.004003
Current version/release in rawhide: 2.004000-3.fc33
URL: http://search.cpan.org/dist/Moo/

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


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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2aa68c5f5e   
tor-0.4.3.7-1.el8
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-317c124dc0   
rpki-client-6.8p1-1.el8
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6c93c61069   
pngcheck-2.4.0-2.el8
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b3000c1eea   
seamonkey-2.53.5-2.el8
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5b5debb24b   
chromium-86.0.4240.198-1.el8


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

et-6.0.13-1.el8
mock-core-configs-33.3-1.el8
powerline-2.8-3.el8
python-jsonref-0.2-1.el8
root-6.22.04-1.el8
safekeep-1.5.1-1.el8

Details about builds:



 et-6.0.13-1.el8 (FEDORA-EPEL-2020-a7bbcefdfd)
 Remote shell that survives IP roaming and disconnect

Update Information:

- Fix warning by systemctl - Test jumphost - --v is not an accepted option  see
https://github.com/MisterTea/EternalTerminal/commits/master

ChangeLog:

* Thu Nov 19 2020 Michel Alexandre Salim  - 6.0.13-1
- Update to 6.0.13
* Thu Nov  5 2020 Filipe Brandenburger  - 6.0.11-3
- Go back to using protobuf-lite on epel8, since the -devel package
  for it is now available (rhbz#1787458).

References:

  [ 1 ] Bug #1899319 - et-6.0.13 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1899319




 mock-core-configs-33.3-1.el8 (FEDORA-EPEL-2020-c98664b593)
 Mock core config files basic chroots

Update Information:

mock-core-configs v33.1 - v33.3  - ELN fixups (mmath...@redhat.com,
jkone...@redhat.com) - EPEL: fix repo-id and name= - Add missing repos to CentOS
6 and CentOS 7 configs - Do --disablerepo=centos-sclo* in templates - Add plain
CentOS 6/7/8 configs (without epel) - EPEL Playground depends on normal EPEL

ChangeLog:

* Fri Nov 20 2020 Pavel Raiskup  33.3-1
- ELN should use for build Everything repository (jkone...@redhat.com)
* Wed Nov 11 2020 Pavel Raiskup  33.2-1
- Add missing CRB repository (jkone...@redhat.com)
* Wed Nov 11 2020 Pavel Raiskup  33.1-1
- ELN fixups (mmath...@redhat.com)
- EPEL: fix repo-id and name=
- Add missing repos to CentOS 6 and CentOS 7 configs
- Do --disablerepo=centos-sclo* in templates
- Add plain CentOS 6/7/8 configs (without epel)
- EPEL Playground depends on normal EPEL




 powerline-2.8-3.el8 (FEDORA-EPEL-2020-758a288b28)
 The ultimate status-line/prompt utility

Update Information:

Initial release of Powerline for EPEL 8

ChangeLog:


References:

  [ 1 ] Bug #1755791 - [RFE] : powerline : epel8 build request
https://bugzilla.redhat.com/show_bug.cgi?id=1755791




 python-jsonref-0.2-1.el8 (FEDORA-EPEL-2020-3c5b165c74)
 An implementation of JSON Reference for Python

Update Information:

Initial package.

ChangeLog:





 root-6.22.04-1.el8 (FEDORA-EPEL-2020-9badca21dd)
 Numerical data analysis framework

Update Information:

ROOT 6.22.04

ChangeLog:

* Fri Nov 13 2020 Mattias Ellert  - 6.22.04-1
- Update to 6.22.04
- Drop patch root-xrootd5-compat.patch (accepted upstream)
* Sat Nov  7 2020 Mattias Ellert  - 6.22.02-4
- Rebuild for C++ standard library __GLIBCXX__ 20201016

[Bug 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-28884abbdf has been pushed to the Fedora 31 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-28884abbdf`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-28884abbdf

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 1899971] perl-CPAN-Perl-Releases-5.20201120 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
FEDORA-2020-1a6103fbf1 has been pushed to the Fedora 31 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-1a6103fbf1`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1a6103fbf1

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 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-2020b5d983 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-2020b5d983`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-2020b5d983

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 1899971] perl-CPAN-Perl-Releases-5.20201120 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-877a7681ef 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-877a7681ef`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-877a7681ef

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 1899767] perl-HTTP-Cookies-6.09 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-6c21ba0c74 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-6c21ba0c74`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-6c21ba0c74

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 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-70e8241280 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-70e8241280`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-70e8241280

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 1899971] perl-CPAN-Perl-Releases-5.20201120 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-8b513d860a 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-8b513d860a`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-8b513d860a

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 1899984] perl-Devel-PatchPerl-2.04 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-a232dec8a0 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-a232dec8a0`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a232dec8a0

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 1899767] perl-HTTP-Cookies-6.09 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-602646558f 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-602646558f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-602646558f

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

[Test-Announce] Proposal to CANCEL: 2020-11-23 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't
have anything urgent this week. blockerbugs is a hot topic of
discussion right now, but I don't think we need to discuss it in a
meeting, on list and on tickets is working fine.

If you're aware of anything important we have to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-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/test-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

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

[Petr Menšík]

On 11/17/20 10:12 AM, Lennart Poettering wrote:
> On Mo, 16.11.20 21:48, Petr Menšík (pemen...@redhat.com) wrote:
> 
>> But it does not have to learn everything about a server, because it
>> switched the active one. If it has to, try to find way to store server
>> instance features per server IP, not per link.
> 
> We do exactly this. But we also have a grace period after which we
> forget everything again, and go back to the best server feature level again,
> which then takes some time to settle back on the actual server feature
> level.
I think smart RTT checking every few minutes would be better, than
forgetting everything about server always responding quickly.
> 
> When we always use the same server, then we probe it once, and use it
> for the full grace period without any further delays. When we use
> numerous servers, and a different one for each lookup, then this means
> we have to probe each and every single one of them once and that slows
> down things.
You can cache average response time for the server. If answer did not
arrive in triple or usuall RTT, send to other servers too. It should not
be done for each request. Depends on how long grace period, right?
> 
> It's a very easy calulation: if you use n=1 servers for 500 lookups
> within the grace period, you experience 1 slow lookup in the worst
> case that required the feature probing, plus 499 speedy lookups
> because we already knew the earlier probing results. If otoh you use
> n=250 servers for 500 lookups you experience 250 worst case slow
> lookups, since we need to learn for each server individually what it
> can and can't do, plus 250 speedy lookups. And then, after the grace
> period is over, you get another 250 slow lookups...
I would think you can detect almost everything from 2 requests and
replies. Only special workarounds for broken implementations may take more.

It could work by timeout not too visible. It would send few queries to
secondary server, metering averate round-trip time. If it was
significantly better than the current server, switch to it. Unless
connection changed, you can expect previous quirks apply, but still you
can test response time. I think dnsmasq sends ocassinally few requests
to non-primary. If answers don't arrive withing hundreds of ms, try also
others. So user has answer soon and it did measure response time of all
used servers. Even if any of them is offline. It does not have to be 50%
of queries just to test it.
> 
>>> It might be something to add as opt-in, and come with the warning that
>>> you better list DNS servers that aren't crap if you want to use that,
>>> so that we never have to downgrade protocol level, and thus the
>>> learning phase is short.
>>
>> Sure enough, many router DNS implementations are bad or ugly. If it can
>> choose from full featured validated ISP resolver and crappy router
>> implementation, prefer the one with better features. Most likely it is
>> much better maintained as well.
> 
> I am sorry, but that is not a suitable approach for an "edge" DNS
> clients. We need to go through the DNS server info we acquired through
> DHCP or so, since private domains do exist. We must keep router admin
> pages accessible.
I haven't mentioned using any external DHCP client. Problem is, there is
no standard way to configure slit DNS over DHCP. Or even declare private
domains used by local networks via autoconfiguration.

I tried Mikrotik's 'router' name on rawhide container.
# dig @127.0.0.53 router
gives status: NXDOMAIN
# dig @127.0.0.53 router.
gives status: NXDOMAIN

/etc/resolv.conf points to /run/systemd/resolve/resolv.conf
but getent can deliver results. How is that possible?

# getent hosts router
192.168.88.1router

# grep hosts /etc/nsswitch.conf
hosts:  resolve [!UNAVAIL=return] myhostname files mdns4_minimal
[NOTFOUND=return] dns

Of course, Mikrotik supports only DNS, not LLMNR or mDNS.

Are you sure you don't support your router's bogus domain, but forgot
about other vendors?

What I am saying is, resolved might choose only the second server from
DHCP list. Where only first knew about private domains for example. It
is kind of broken configuration, but not uncommon. Router's DNS might be
out of date, vulnerable to various attacks, but would be first IP on DNS
servers from DHCP. Second would be ISP's resolver with up-to-date
security backups. Now, systemd-resolved understands DNS servers as a
set, but not ordered list, right? Would and should it choose ISP's
server or my home router? What are checked metrics?

> 
> Hence, the "server spread" thing where queries are spread over a ton
> of DNS servers only really works if configured for the manual opt-in
> case. It's not something we could ever deploy by default. By default
> we need something that works, doesn't break private domains, and isn't
> slow.
I agree, but just partially. Original behaviour of nss_dns.so plugin was
to always keep order of used DNS servers constant. I am not sure this is
possible to 

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

[Brandon Nielsen]

On 11/20/20 4:31 PM, 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.


It would be great however if the change request clarified what needs to 
be done - especially taking into account that very recent online 
instructions now may be wrong.




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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: PR 4453 - Add options to dsctl to create, delete, and display the .dsrc file

[Mark Reynolds]

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

--

389 Directory Server Development Team
___
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)

[Naheem Zaffar]

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.

It would be great however if the change request clarified what needs to be
done - especially taking into account that very recent online instructions
now may be wrong.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: libcap-ng update coming to rawhide

[Steve Grubb]

On Thursday, November 19, 2020 8:32:38 PM EST Adam Williamson wrote:
> On Wed, 2020-11-18 at 14:32 -0500, Steve Grubb wrote:
> > On Thursday, November 12, 2020 2:45:41 PM EST Steve Grubb wrote:
> > The new libcap-ng has been built into rawhide.
> 
> ...and it does break gnome-keyring, and it also breaks cifs-utils (so
> you can't mount CIFS/SMB shares), as per this upstream bug report:
> 
> https://github.com/stevegrubb/libcap-ng/issues/21

OK. I also see something about VPN openconnect. I'm hoping that's all the 
major pieces.
 
> whose reporter also noted what looks like a valid problem in your
> gnome-keyring fix.

For other distributions, yes. Worked fine on Fedora. A fixed pull request has 
positive comments from the person spotting the issue on another distribution.

> Was it really necessary to build this when you *knew* a major package
> did not work with it? Did you talk to the Workstation folks about
> getting the patch applied to gnome-keyring?

A new package has been pushed that blocks reporting error codes for changing 
bounding sets. If this checks good, I think I can use that refactored code to 
syslog which programs are not using capabilities correctly. But at some point 
in the future, we need to allow real error codes again.

-Steve


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: video meeting to discuss Matrix/Element and IRC

[Daniel Pocock]

On 19/11/2020 19:17, Neal Gompa wrote:
> On Thu, Nov 19, 2020 at 1:09 PM Daniel Pocock  wrote:
>>
>>
>>
>> On 19/11/2020 18:55, Richard W.M. Jones wrote:
>>> On Thu, Nov 19, 2020 at 06:50:21PM +0100, Vitaly Zaitsev via devel wrote:
 On 19.11.2020 18:34, Radka Gustavsson wrote:
> Rich, IRC is not being dropped, it is being bridged to modern,
> "IRC-native" (for lack of better word in my vocabulary) platform.
> Contributors who prefer to stay on IRC are welcome to do so and
> won't really notice any difference.

 No, please. IRC bridges need to be closed to force users to switch
 to Matrix.
>>>
>>> "force"?  You may have said the quiet bit aloud ...
>>
>> yes, it got my attention too
>>
>> I'm not going to give a firm recommendation for or against any platform
>> but I'd like to make two suggestions:
>>
>> a) why not slow the process down and allow more ideas to come forward?
>> There is no urgent need to change things in a month or whatever.
>>
>> b) it is really important to look at the organizational factors and not
>> just the technical factors.  Today, too many organizations allow their
>> culture to be shaped by whatever tool is available.  I'll refrain from
>> giving examples of the disasters that follow.  For any free software
>> organization and any other type of organization too, it needs to be
>> organization first, tool second.
>>
>> Maybe I will recommend a platform...
>>
> 
> The move to having our own Matrix server is being driven by Fedora
> subcommunities already wanting to move primacy from IRC to Matrix.
> Many of our adjunct upstreams have done so (Mozilla, KDE, etc.) or are
> in the process of doing so (GNOME, openSUSE, etc.).
> 
> The intent isn't to drop IRC as a gateway to these communities, and
> indeed the Freenode IRC channels would remain bridged to the Fedora
> Matrix server.
> 
> To be blunt, we're struggling to get new folks to come talk to us on
> IRC. Our largest user community is on Discord today, which eclipses
> *everything* else by a wide margin. Next up is Telegram, which we have
> been using somewhat for years through influence by the Russian Fedora
> community who brought it to us in the first place. Neither of these
> platforms are FOSS, and we want to provide a rich real-time
> communications platform that is FOSS and open in many of the same ways
> that IRC is. Matrix is open, federated, and gaining share in the
> marketplace, making it a solid replacement for IRC. And unlike
> alternatives, maintaining links to historical IRC channels with Matrix
> rooms is easy and straightforward.
> 
> We want to be approachable, and we want to be appealing. Right now,
> our usage of IRC hurts us. The Matrix makeover can help smooth out
> those issues without leaving behind the folks who prefer the IRC
> interface.

This aspect of using Matrix definitely lowers the risk

Nonetheless, a lot of people still misrepresent Matrix as a fully
federated or peer-to-peer solution when it isn't quite there yet.  The
Matrix developers clearly state[1] that the Identity Server concept is a
work in progress.  In its current form, that part of the platform is
still somewhat centralized but better than an entirely closed platform.

Overall, I still think there are higher level issues that go along with
this.  For example, some of the work I've done around iCalendar and task
lists is intended to encourage people to think about how they manage
their time on these platforms and ensure the right people are in the
right call/chat session at the same time to make decisions together.  I
know that sounds quite basic but it doesn't always happen.  It is not
always about which tool people are using, sometimes organizations are
just not managing calendars in an efficient manner.

Regards,

Daniel


1. https://matrix.org/faq/#can-i-run-my-own-identity-server%3F
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: video meeting to discuss Matrix/Element and IRC

[John M. Harris Jr]

On Friday, November 20, 2020 11:52:46 AM MST Radka Gustavsson wrote:
> On Fri, Nov 20, 2020 at 6:03 PM John M. Harris Jr 
> 
> wrote:
> > On Thursday, November 19, 2020 11:17:15 AM MST Neal Gompa wrote:
> > > The move to having our own Matrix server is being driven by Fedora
> > > subcommunities already wanting to move primacy from IRC to Matrix.
> > > Many of our adjunct upstreams have done so (Mozilla, KDE, etc.) or are
> > > in the process of doing so (GNOME, openSUSE, etc.).
> > > 
> > > The intent isn't to drop IRC as a gateway to these communities, and
> > > indeed the Freenode IRC channels would remain bridged to the Fedora
> > > Matrix server.
> > > 
> > > To be blunt, we're struggling to get new folks to come talk to us on
> > > IRC.
> > 
> > Has this been documented anywhere? If so, we can likely review these
> > issues,
> > and see what would need to be done to solve this problem, if there is one.
> > 
> > > Our largest user community is on Discord today, which eclipses
> > > *everything* else by a wide margin.
> > 
> > It's worth questioning whether those folks are actually Fedora uses, or
> > people
> > who are just a bit interested in Fedora. Given that the use of proprietary
> > software, where a superior Free alternative exists, is against the Four
> > Foundations, it's questionable that they'd be Discord users.
> 
> I manage the place we're talking about so I can tell you all about it. Many
> open source lovers use Discord. Quite a few became Fedora contributors
> through our Discord community as well. Perhaps you shouldn't judge without
> ever participating. People aren't automatically bad or whatever just
> because they don't mind using proprietary software when its benefits far
> outweigh the downsides and when it enables them to work at their peak
> efficiency.

I never said that anyone was "bad or whatever" for using proprietary software. 
I'm not going to get much further into this, because I don't want this to 
become another pile-on, but Discord is hardly the most efficient chat option. 
I've seen videos of its use, and we have Free Software that meets and exceeds 
the needs that Discord also offers a solution to.

> Discord is in fact an amazing chat platform for the end user that doesn't
> have a peer out there. (I could talk for hours about its flaws, but the end
> user won't notice or realise most of them.) You're extremely wrong in
> saying that there is a "superior" libre alternative. There isn't, nowhere
> near. If there was, it would have been popular and not Discord. Those
> masses chose it for its features and ease of use. It allows people to do
> whatever they want and doesn't disable anyone, regardless how "out there"
> their requirements may be.

We're just going to have to disagree on that one. I look forward to hearing 
about the new hotness in a few more years.

> Our Discord community is not "against the Four Foundations" like you say.

I didn't say that it was. This has been clarified by the Council at this 
point, it's not an official communication platform, it's just treated as a 
social media account.

> It definitely hits 3/4 - Features Friends and First, and by proxy, by
> enabling people to reach Fedora contributors easier, it also enables the
> FREE in the end, by further contribution from the members. I could easily
> turn your logic against IRC - it's definitely not First to introduce new
> Features and because of it, it doesn't bring Friends together anymore. All
> it's got really going for it is the FREE.

Discord is not Free Software. In this context, Free refers not to price, but 
to freedom. Libre, not gratis.

-- 
John M. Harris, Jr.

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

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

[Brandon Nielsen]

On 11/20/20 1:28 PM, Dominique Martinet wrote:

Ben Cotton wrote on Fri, Nov 20, 2020:

== How To Test ==
This change needs to be tested on as many different audio cards as
possible. The same test plan applies here as with PulseAudio.

To test, one needs to install 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

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

[José Abílio Matos]

On Friday, November 20, 2020 4:26:53 PM WET Ben Cotton wrote:
> == Release Notes ==
> The GNU Compiler Collection version 11 will be released shortly. See
> https://gcc.gnu.org/gcc-11/changes.html.
> 
> The GNU C Library version 2.32 will be released at the beginning of
> August 2020. The current NEWS notes can be seen here as they are
> added: https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS;hb=HEAD

Just a small note, glibc was *already* released. :-)
Please update the release notes.

-- 
José Abílio___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

[Dominique Martinet]

Ben Cotton wrote on Fri, Nov 20, 2020:
> == How To Test ==
> This change needs to be tested on as many different audio cards as
> possible. The same test plan applies here as with PulseAudio.
> 
> To test, one needs to install the pipewire-pulse library (which
> removes the pulseaudio package).

Took me some time to figure out how to test:
 - there's no such package; there's a pipewire-libpulse that apparently
got integrated into pipewire-libs but doesn't replace pulseaudio unlike
the comment above (in fc33's update-testing pipewire-0.3.16-1.fc33.x86_64)
 - /usr/share/doc/pipewire/README.md talks about pw-pulse  to
test but not how to replace the user's pulse socket
 - there's pipewire-pulse and a pipewire.socket/service user service in
(the new) pipewire package, but the user service doesn't start
pipewire-pulse (unless the exec is commented out in the config maybe?)

I ended up manually removing the socket at /run/user//pulse/native,
starting pipewire-pulse manually and killing the old pulseaudio instance
but I'm sure there's a better way?


I've messed around with (very casual) things and everything appears to
work, with pipewire-pulse spewing some warnings when I tried pavucontrol

[W][001555077.904969][pulse-server.c:411 reply_error()] pulse-server
0x56434a66a640: [PulseAudio Volume Control] ERROR command:87 (EXTENSION)
tag:17 error:19 (Operation not supported)

and errors when a client disconnect

[E][00197.840471][core.c:71 core_event_error()] core 0x56434a67f520:
proxy 0x56434a67f520 id:0: bound:-1 seq:667 res:-22 (Invalid argument)
msg:"unknown resource 40 op:3"


both are probably harmless, and that aside everything looks great; I
think making things easier to test (or clarifying the procedure) for
fedora 33 would help reassuring people about it.


Haven't tested the jack side of things as I don't use it normally.
-- 
Dominique
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: video meeting to discuss Matrix/Element and IRC

[Jared K. Smith]

On Fri, Nov 20, 2020 at 2:00 PM Kevin Fenzi  wrote:

> IMHO editing is fine, as long as it notes it was edited and provides you
> a way to see what was changed. I have no idea how the matrix editing
> works however.
>

As I recall, it puts a small "(edited)" notice at the end of the line to
let you know that it was edited.

-Jared
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: video meeting to discuss Matrix/Element and IRC

[Radka Gustavsson]

On Fri, Nov 20, 2020 at 7:56 PM Kevin Fenzi  wrote:

> On Fri, Nov 20, 2020 at 11:27:08AM +0100, Marius Schwarz wrote:
> > Am 19.11.20 um 21:13 schrieb José Abílio Matos:
> > >
> > > On Thursday, November 19, 2020 5:54:52 PM WET Richard W.M. Jones wrote:
> > >
> > > > I'm not sure that message editing is a feature.
> > >
> > >
> > > In fairness as long as the grace period is fixed and small that is not
> a
> > > bad thing.
> > >
> > > E.g it allows you to fix lots of cases where you found that the message
> > > was incomplete after sending it or it had incorrect information that
> you
> > > only found after sending it.
> > >
> > >
> > > That allows to clean some noise and it is not a bad thing. :-)
> >
> > Just imagine to fix a typo in a cmd you gave as advise.. it's very
> usefull.
>
> Sure, but also imagine:
>
> usera: "Hey everyone, say yea, Fedora is great!"
> userb: "yea!"
> userc: "yea!"
> usera  "Say yea if you love osx!"
>
> IMHO editing is fine, as long as it notes it was edited and provides you
> a way to see what was changed. I have no idea how the matrix editing
> works however.
>

That's what moderators are for who can see edits. But even then, in so many
years on Discord, never had that problem in any of the many and large
communities that I manage. Users know that they get in trouble if they try
to do such things.


>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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)

[Erich Eickmeyer]

On 11/20/20 8:36 AM, Vitaly Zaitsev via devel wrote:
IMO, too early. PipeWire is too unstable yet. I suggest postpone this 
proposal to Fedora 35.


The person who wrote the change proposal is the lead developer of 
Pipewire. He believes it is stable enough (or will be) by the time F34 
branches. And to be honest, it won't get enough testing without being 
*at least* submitted to Rawhide.


With my Fedora Jam hat on (read: professional audio), I believe it's the 
right move. It's stable *enough* and needs to be tested by the public. 
If it's still too unstable, then there's a contingency plan. BUT, if we 
don't move forward *now* we'll wait another decade, and be in the same 
situation that Wayland is in.


The time to move forward is *now*. If we keep being scared, we'll never 
get anywhere.


--
Erich Eickmeyer
Maintainer
Fedora Jam
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 Fri, 2020-11-20 at 17:36 +0100, Vitaly Zaitsev via devel wrote:
> On 20.11.2020 17:26, Ben Cotton wrote:
> > This change proposal is to route all audio from PulseAudio and JACK to
> > the PipeWire Audio daemon by default.
> 
> IMO, too early. PipeWire is too unstable yet. I suggest postpone this 
> proposal to Fedora 35.

Do you have any data to support this assertion?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
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: video meeting to discuss Matrix/Element and IRC

[Radka Gustavsson]

On Fri, Nov 20, 2020 at 6:03 PM John M. Harris Jr 
wrote:

> On Thursday, November 19, 2020 11:17:15 AM MST Neal Gompa wrote:
> > The move to having our own Matrix server is being driven by Fedora
> > subcommunities already wanting to move primacy from IRC to Matrix.
> > Many of our adjunct upstreams have done so (Mozilla, KDE, etc.) or are
> > in the process of doing so (GNOME, openSUSE, etc.).
> >
> > The intent isn't to drop IRC as a gateway to these communities, and
> > indeed the Freenode IRC channels would remain bridged to the Fedora
> > Matrix server.
> >
> > To be blunt, we're struggling to get new folks to come talk to us on
> > IRC.
>
> Has this been documented anywhere? If so, we can likely review these
> issues,
> and see what would need to be done to solve this problem, if there is one.
>
> > Our largest user community is on Discord today, which eclipses
> > *everything* else by a wide margin.
>
> It's worth questioning whether those folks are actually Fedora uses, or
> people
> who are just a bit interested in Fedora. Given that the use of proprietary
> software, where a superior Free alternative exists, is against the Four
> Foundations, it's questionable that they'd be Discord users.
>

I manage the place we're talking about so I can tell you all about it. Many
open source lovers use Discord. Quite a few became Fedora contributors
through our Discord community as well. Perhaps you shouldn't judge without
ever participating. People aren't automatically bad or whatever just
because they don't mind using proprietary software when its benefits far
outweigh the downsides and when it enables them to work at their peak
efficiency.

Discord is in fact an amazing chat platform for the end user that doesn't
have a peer out there. (I could talk for hours about its flaws, but the end
user won't notice or realise most of them.) You're extremely wrong in
saying that there is a "superior" libre alternative. There isn't, nowhere
near. If there was, it would have been popular and not Discord. Those
masses chose it for its features and ease of use. It allows people to do
whatever they want and doesn't disable anyone, regardless how "out there"
their requirements may be.

Our Discord community is not "against the Four Foundations" like you say.
It definitely hits 3/4 - Features Friends and First, and by proxy, by
enabling people to reach Fedora contributors easier, it also enables the
FREE in the end, by further contribution from the members. I could easily
turn your logic against IRC - it's definitely not First to introduce new
Features and because of it, it doesn't bring Friends together anymore. All
it's got really going for it is the FREE.


>
> > Next up is Telegram, which we have
> > been using somewhat for years through influence by the Russian Fedora
> > community who brought it to us in the first place. Neither of these
> > platforms are FOSS, and we want to provide a rich real-time
> > communications platform that is FOSS and open in many of the same ways
> > that IRC is. Matrix is open, federated, and gaining share in the
> > marketplace, making it a solid replacement for IRC. And unlike
> > alternatives, maintaining links to historical IRC channels with Matrix
> > rooms is easy and straightforward.
> >
> > We want to be approachable, and we want to be appealing. Right now,
> > our usage of IRC hurts us.
>
> If Matrix bridges so well with IRC, and many upstream communities are
> using it
> already, surely they could just join our channels through their bridges?
>
> --
> John M. Harris, Jr.
> Splentity
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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: video meeting to discuss Matrix/Element and IRC

[Kevin Fenzi]

On Fri, Nov 20, 2020 at 11:27:08AM +0100, Marius Schwarz wrote:
> Am 19.11.20 um 21:13 schrieb José Abílio Matos:
> > 
> > On Thursday, November 19, 2020 5:54:52 PM WET Richard W.M. Jones wrote:
> > 
> > > I'm not sure that message editing is a feature.
> > 
> > 
> > In fairness as long as the grace period is fixed and small that is not a
> > bad thing.
> > 
> > E.g it allows you to fix lots of cases where you found that the message
> > was incomplete after sending it or it had incorrect information that you
> > only found after sending it.
> > 
> > 
> > That allows to clean some noise and it is not a bad thing. :-)
> 
> Just imagine to fix a typo in a cmd you gave as advise.. it's very usefull.

Sure, but also imagine: 

usera: "Hey everyone, say yea, Fedora is great!" 
userb: "yea!"
userc: "yea!"
usera  "Say yea if you love osx!"

IMHO editing is fine, as long as it notes it was edited and provides you
a way to see what was changed. I have no idea how the matrix editing
works however. 

kevin


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

Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

[Kevin Fenzi]

On Fri, Nov 20, 2020 at 11:16:03AM -0500, Matthew Miller wrote:
> On Fri, Nov 20, 2020 at 12:03:27AM +0100, Emmanuel Seyman wrote:
> > I suspect that these packages are maintained only to the point where they
> > can build (and thus be used as buildreqs) but their maintainer also doesn't
> > want them to be updated without making sure that the update will not break
> > the package they are really interested in.
> 
> That's probably also true. So communicating that reverse-dependency might be
> another important aspect. CI gating should in theory help here.
> 
> > What exactly do you want to do with this list of lightly-maintained 
> > packages?
> > 
> > Is this something you want to present to end-users?
> 
> Yes.

Well, I'm not sure how we would do this. I mean a 'normally maintained'
package still means the end-user should expect the maintainer to solve
their bug when they are willing and able to do so. We don't promise any
kind of turnaround on issues or deadlines on things. 
So how would a 'lightly maintained' package be different here?

> > Is this a list we should show to people tempted to become packagers?
> 
> Possibly? Maybe more appropriate for packagers interested in increasing
> overall packaging quality.
> 
> > Do we want to generate auto-replies to bugs filed in Bugzilla?
> 
> Yes, I think so. Explaining the situation and asking for help. We may also
> want to have a process for making sure that bugs which actually might
> percolate up to the actual package of interest don't get discarded. 

The problem there is that there are lots of reasons for different maint
levels, and it's hard to image a generic template handling that. 

Even if we bundle all the ones specifically in this exact case "I only
maintain these packages because I care about 1 thing that uses them",
it's hard to explain to users the expectation here. Imagine a bug
against one of these packages that: 

* bumps to a new release/version. This might be fine, if the 1 package
you care about still works fine, but might be something you reject if it
doesn't. I suppose you could ask the user to test it and let you know?

* Fixes some cosmetic bug that has nothing to do with how it's being
used by the one package. If the maintainer had time they could
apply/build this, but again would have to make sure it doesn't affect
the thing they care about. 

* Is some complex thing that needs a bunch of investigation. I don't
think the maintainer of the one thing will have time/energy to do
that now, but not sure who would if we tell the user more? "The
maintainer doesn't care about your bug because they only care about
package X, you are on your own" is I suppose a bit better than silence
in some ways. 

* Complains about an update that was needed for the one package. I would
think this would be closed, sorry, nothing I can do either way?

In the last FESCo meeting we got off on a bit of a tanget here talking
about how we might look at improving all bug handling somehow. I think
it might be constructive to look into ideas around that and they might
help these 'lightly maintained' packages too?

It's not a easy problem for sure. ;( 

There's currently 16,288 bugs against fedora components. 
About 84% of them are in "NEW" state. 
570 bugs were opened in the last 7 days
555 bugs were closed in the last 7 days. 
(So, I guess right now we are treading water)

The top 10 packages bug counts are not too surprising: 

kernel  1040
Package Review  730 
gnome-shell 286 
anaconda267 
selinux-policy  241 
dnf 215 
firefox 157 
distribution139 
systemd 131 
NetworkManager  95

Interestingly, 40% of our open bugs are against rawhide. 
Thats pretty amazing considering we move rawhide bugs to branched when
we branch, so those 40% were all filed in the last months.

> 
> 
> > Should SIGs keep a lookout for security fixes to apply?
> 
> That would be awesome in general, I think.

Always a good idea.

kevin


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

[389-devel] Please review: PR 4451 - dsconf replication monitor fails to retrieve consumer RUV

[Pierre Rogier]

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

-- 
--

389 Directory Server Development Team
___
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: video meeting to discuss Matrix/Element and IRC

[Simo Sorce]

On Fri, 2020-11-20 at 09:14 -0800, Adam Williamson wrote:
> On Fri, 2020-11-20 at 08:32 -0500, Simo Sorce wrote:
> > On Thu, 2020-11-19 at 23:14 -0500, Matthew Miller wrote:
> > > On Fri, Nov 20, 2020 at 02:06:46AM +0100, Dominik 'Rathann' Mierzejewski 
> > > wrote:
> > > > > > No, you don't. I've just joined a random room without any kind of
> > > > > > registration. Try it yourself if you don't believe me:
> > > > > > https://app.element.io/#/room/#lounge:privacytools.io
> > > > > You are able to view it but are you able to participate?  If not, you
> > > > > haven't joined
> > > > I know the difference and yes, you're able to participate without
> > > > registration in that room.
> > > 
> > > When I view this room in a private browser window, I can see the
> > > conversation, but at the bottom, it says "Join the conversation with an
> > > account" and presents "Sign In" / "Sign Up" buttons.
> > 
> > Good for you, this is what I got:
> > 
> >Failed to start
> >Your Element is misconfigured
> > 
> >Invalid homeserver discovery response
> > 
> > Sounds like if you already are a user it works, otherwise not
> 
> Are you using a blocker like uMatrix? If so that's likely the issue.
> element.io uses a ton of elements from matrix.org, and if those are
> blocked, that's the error you get.

No blockers no this machine, but after a few reloads it started
working, not sure what was the cause. Possibly a bad reaction at not
finding any cookie at all (given it was the first time I ever logged on
element.io properties). I've seen race conditions like that before on
sites that sprawl requests across multiple properties and expect a
consistent view.

Simo.

> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> 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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: video meeting to discuss Matrix/Element and IRC

[Adam Williamson]

On Fri, 2020-11-20 at 08:32 -0500, Simo Sorce wrote:
> On Thu, 2020-11-19 at 23:14 -0500, Matthew Miller wrote:
> > On Fri, Nov 20, 2020 at 02:06:46AM +0100, Dominik 'Rathann' Mierzejewski 
> > wrote:
> > > > > No, you don't. I've just joined a random room without any kind of
> > > > > registration. Try it yourself if you don't believe me:
> > > > > https://app.element.io/#/room/#lounge:privacytools.io
> > > > You are able to view it but are you able to participate?  If not, you
> > > > haven't joined
> > > I know the difference and yes, you're able to participate without
> > > registration in that room.
> > 
> > When I view this room in a private browser window, I can see the
> > conversation, but at the bottom, it says "Join the conversation with an
> > account" and presents "Sign In" / "Sign Up" buttons.
> 
> Good for you, this is what I got:
> 
>    Failed to start
>    Your Element is misconfigured
> 
>    Invalid homeserver discovery response
> 
> Sounds like if you already are a user it works, otherwise not

Are you using a blocker like uMatrix? If so that's likely the issue.
element.io uses a ton of elements from matrix.org, and if those are
blocked, that's the error you get.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
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: video meeting to discuss Matrix/Element and IRC

[Vitaly Zaitsev via devel]

On 20.11.2020 17:59, John M. Harris Jr wrote:

Given that the use of proprietary
software, where a superior Free alternative exists, is against the Four
Foundations, it's questionable that they'd be Discord users.


Discord also has the worst terms of service I've ever seen.

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

Re: video meeting to discuss Matrix/Element and IRC

[Adam Williamson]

On Fri, 2020-11-20 at 11:19 +0100, Marius Schwarz wrote:
> Am 19.11.20 um 23:42 schrieb Adam Williamson:
> > The chat history persistence - and seamless use across devices - is a
> > huge advantage. The other advantage is that you can sign up for and use
> > this system simply and entirely in a web browser, a process people are
> > comfortable with. It is similar to systems they may well already be
> > familiar with, like Slack and Discord. People are not comfortable with
> Discord is the best example on how to not have an age old history. If 
> you have joined only one of those, you get blinded by blinking 
> emotiocons, animgifs  etc.
> 
> That is the opposite of helpful while discussing important things. In a 
> Hello Kitty context, as entertainment, it may have it's usecase for 
> those impacted.

*shrug* I disagree. I'm on quite a few discord servers and I enjoy it.
Reactions, in particular, are super useful because they let people do
simple stuff like registering amusement or agreement with something
without having to actually send a message themselves.

It is also useful for keeping up with the zoomers. We're all going to
be yelling at clouds some day, but I like to try and delay it as much
as possible. :P

(also note there's nothing stopping people sending emoticons over IRC,
at least if the server and client both support UTF-8...)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
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: video meeting to discuss Matrix/Element and IRC

[John M. Harris Jr]

On Thursday, November 19, 2020 11:17:15 AM MST Neal Gompa wrote:
> The move to having our own Matrix server is being driven by Fedora
> subcommunities already wanting to move primacy from IRC to Matrix.
> Many of our adjunct upstreams have done so (Mozilla, KDE, etc.) or are
> in the process of doing so (GNOME, openSUSE, etc.).
> 
> The intent isn't to drop IRC as a gateway to these communities, and
> indeed the Freenode IRC channels would remain bridged to the Fedora
> Matrix server.
> 
> To be blunt, we're struggling to get new folks to come talk to us on
> IRC.

Has this been documented anywhere? If so, we can likely review these issues, 
and see what would need to be done to solve this problem, if there is one.

> Our largest user community is on Discord today, which eclipses
> *everything* else by a wide margin.

It's worth questioning whether those folks are actually Fedora uses, or people 
who are just a bit interested in Fedora. Given that the use of proprietary 
software, where a superior Free alternative exists, is against the Four 
Foundations, it's questionable that they'd be Discord users.

> Next up is Telegram, which we have
> been using somewhat for years through influence by the Russian Fedora
> community who brought it to us in the first place. Neither of these
> platforms are FOSS, and we want to provide a rich real-time
> communications platform that is FOSS and open in many of the same ways
> that IRC is. Matrix is open, federated, and gaining share in the
> marketplace, making it a solid replacement for IRC. And unlike
> alternatives, maintaining links to historical IRC channels with Matrix
> rooms is easy and straightforward.
> 
> We want to be approachable, and we want to be appealing. Right now,
> our usage of IRC hurts us.

If Matrix bridges so well with IRC, and many upstream communities are using it 
already, surely they could just join our channels through their bridges?

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: video meeting to discuss Matrix/Element and IRC

[John M. Harris Jr]

On Thursday, November 19, 2020 10:34:28 AM MST Radka Gustavsson wrote:
> On Thu, Nov 19, 2020 at 6:11 PM Richard W.M. Jones 
> 
> wrote:
> > On Wed, Nov 18, 2020 at 12:22:26PM -0500, Matthew Miller wrote:
> > > [I posted to the Fedora Council list, but reposting here for wider
> > > distribution.]
> > > 
> > > As mentioned, we're looking at moving the Fedora Council's main chat to
> > > Matrix. And as part of that, we're considering a hosted Element server
> > > --
> > > which obviously could go quite beyond just #fedora-council. Neal
> > 
> > suggested a
> > 
> > > video meeting to talk with interested people about this, and so I set up
> > > this when-is-good
> > > 
> > >http://whenisgood.net/k5brwbd
> > > 
> > > Anyone interested in a preliminary chat about all of this, please sign
> > > up
> > > with your FAS id and availability. Nothing is sent in stone or decided
> > > already, although I must say I'm pretty excited about Element's open
> > 
> > source
> > 
> > > software-as-a-service offering based on what I've heard from them so
> > > far.
> > 
> > There's quite a lot wrong here - a video meeting(!) to discuss
> > dropping a commonly used and well established channel of
> > communication.  Well, I guess at least you didn't decide to use the
> > proprietary awfulness of Slack.
> 
> Rich, IRC is not being dropped, it is being bridged to modern, "IRC-native"
> (for lack of better word in my vocabulary) platform. Contributors who
> prefer to stay on IRC are welcome to do so and won't really notice any
> difference.
> 
> > Couldn't you just talk about this on email?
> 
> https://discussion.fedoraproject.org/t/the-future-of-real-time-chat-discussi
> on-for-the-fedora-council/24628
> > Let me start off:
> > 
> > What's the reason why hosting your own server for a fairly uncommon
> > chat protocol is better than continuing to use IRC?
> 
> I too love dinosaurs... but I also work on 4 different computers and two
> mobile devices every day. Having to literally switch hardware to
> participate in IRC meetings is pain in the ass for some of our contributors
> (myself included.)

Have you considered using a bouncer, similar software or weechat/irssi, such 
that you don't have to switch hardware? This kind of software has become much 
easier to use these days, and there are many services available with web based 
options if you are uncomfortable with configuring software yourself.

-- 
John M. Harris, Jr.
Splentity

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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)

[Simo Sorce]

On Fri, 2020-11-20 at 11:26 -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/DefaultPipeWire
> 
> == Summary ==
> This change proposal is to route all audio from PulseAudio and JACK to
> the PipeWire Audio
> daemon by default.
> 
> == Owner ==
> * Name: [[User:Wtaymans| Wim Taymans]]
> * Email: wim.taym...@gmail.com
> 
> 
> == Detailed Description ==
> Currently, all desktop audio is handled by the PulseAudio daemon.
> Applications make use of the
> PulseAudio client library to communicate with the PulseAudio daemon
> that mixes and manages the audio streams from the clients.
> 
> The desktop shell (gnome-shell) and the control panel
> (gnome-control-panel) both use the
> Pulseaudio client libraries to manage the volume and configuration of
> the PulseAudio daemon.
> 
> 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.
> 
> All PRO audio is handled with the JACK client library, which talks to
> the JACK server. This
> proposal will install a JACK client library replacement that talks
> directly to PipeWire. All
> existing PRO audio jack applications will then work on top of PipeWire.
> 
> For legacy ALSA clients, we will install an ALSA plugin that routes
> the audio directly to
> PipeWire.
> 
> With these 3 changes, all audio will be routed to PipeWire. There will
> then be no more need to
> install the PulseAudio and JACK daemons.
> 
> == Feedback ==
> The owner of this proposal has been in context with both the
> PulseAudio and JACK maintainers and community.
> PipeWire is considered to be the successor of both projects.
> 
> == Benefit to Fedora ==
> The end goal is to end up with one audio infrastructure for both
> Desktop and Pro audio use cases.
> This will end the fragmentation of the audio landscape.
> 
> Some of the benefits that PipeWire will bring:
> 
>  * PRO Audio features
> 
>PipeWire can support both Desktop and PRO Audio use cases. PRO
> Audio application tend to use
>the JACK API and JACK daemon, which is hard to setup and integrates
> poorly with the rest of
>the system (and PulseAudio in particular).
> 
>With a replacement libjack library, PRO Audio application can run
> directly on PipeWire and
>integrate seamlessly with other ALSA and PulseAudio applications.
> This would bring Fedora
>closer to the experience of other operating systems.
> 
>  * Flexibility/Integration
> 
>PipeWire is designed to be multiprocess. It separates the
> processing of the multimedia graph
>and the management into separate processes. This makes it possible
> to better integrate with
>the other system components or swap out the default policy for a
> highly customized one (such as
>for automotive or embedded). This is in contrast to PulseAudio,
> which has all logic embedded
>into the daemon with limited configuration options.
> 
>In the next phase we expect to greatly expand the user experience
> and configuration of the
>audio infrastructure with better integration throughout the system.
> 
>  * Performance
> 
>PipeWire was designed for high performance and low-latency, using
> much of the same design as
>JACK. JACK application should run with comparable performance even
> in low-latency situations.
> 
>  * Security
> 
>PipeWire enforces per client security. Object visibility and the
> actions on them can be
>configured independently per client. This makes it possible to
> enforce a security policy for
>sandboxed applications (Flatpak) such as denying access to certain
> audio capture devices or
>block them from interfering with other applications.
> 
>  * Maintainability
> 
>Both PulseAudio and JACK have very slow development cycles with few
> new features. The more
>flexible and distributed nature of the design of PipeWire should
> encourage more new features
>and use-cases.
> 
> == Scope ==
> * Proposal owners:
> We would make a pipewire-pulse package that provides the same features
> as the pulseaudio (daemon) package.
> We would only provide a drop-in replacement daemon, the pulseaudio
> client libraries will remain unchanged.
> 
> The idea is that when installing pipewire-pulse, only the pulseaudio
> package is removed and replaced by the
> pipewire-pulse implementation. In the same way, installing the
> pulseaudio package would remove the pipewire-pulse
> package, making it possible to switch between implementations. This
> will also allow for an easy rollback.
> 
> We also need to check and correct the dependencies of other packages.
> As of this writing, some packages do
> not state their dependencies correctly and get removed when pulseaudio
> is removed. We also need to check the
> JACK to make sure they still install with the replacement JACK client library.
> 
> The JACK 

Re: video meeting to discuss Matrix/Element and IRC

[Vitaly Zaitsev via devel]

On 20.11.2020 17:18, Matthew Miller wrote:

Yes, I don't see why not. As I understand it, if your server becomes a
source of spam or whatever, we can block it. But I trust that it won't.


Public registration is disabled on it. Only me and my friends can use it.

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

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

[Vitaly Zaitsev via devel]

On 20.11.2020 17:26, Ben Cotton wrote:

This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio daemon by default.


IMO, too early. PipeWire is too unstable yet. I suggest postpone this 
proposal to Fedora 35.


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

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

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

> The binutils 2.35 change is being tracked here:
> https://fedoraproject.org/wiki/Changes/BINUTILS235
> 
> The gcc 11 and glibc 2.33 change will be tracked in this top-level GNU
> Toolchain system-wide update.
> 
> == Owner ==
> * Name: [[User:codonell|Carlos O'Donell]], [[User:law|Jeff Law]]
> * Email: car...@redhat.com, l...@redhat.com
> 
> 
> == Detailed Description ==
> The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities
> make up the core part of the GNU Toolchain and it is useful to
> transition these components as a complete implementation when making a
> new release of Fedora.
> 
> The GNU Compiler Collection will be releasing version 11 containing
> many new features documented here:
> https://gcc.gnu.org/gcc-11/changes.html.  Historically pre-releases of
> GCC drop into Fedora in Jan/Feb just prior to the mass rebuild.  The
> major process change this year is the desire to drop in snapshots of
> GCC 11 into rawhide starting in November with updates throughout the
> Fedora 34 release process as needed.
> 
> The GNU C Library version 2.33 will be released at the beginning of
> February 2020; we have started closely tracking the glibc 2.33
> development code in Fedora Rawhide and are addressing any issues as
> they arise. Given the present schedule Fedora 34 will branch after the
> glibc 2.33 upstream release. However, the mass rebuild schedule means
> Fedora 34 will mass rebuild (if required) after glibc 2.33 upstream
> freezes ABI for release, but before the actual release, so careful
> attention must be paid to any last minute ABI changes.
> 
> == Benefit to Fedora ==
> Stays up to date with latest features, improvements security and bug
> fixes from gcc and glibc upstream.
> 
> The change to drop GCC 11 snapshots into rawhide earlier is meant to
> start more wide scale testing of GCC earlier.  This means that package
> maintainers will not be faced with a onslaught on FTBFS issues in
> Feb/Mar and the GCC maintainers will not be as stressed trying to fix
> all Fedora related issues in a short time frame as well.
> 
> == Scope ==
> The gcc and glibc teams will need to move their respective upstream
> projects to a releasable state.  For GCC this includes correctly
> building Fedora rawhide.
> 
> * Other developers: Developers need to ensure that gcc, binutils, and
> glibc in rawhide is stable and ready for the Fedora 34 branch. Given
> that glibc is backwards compatible and we have been testing the new
> glibc in rawhide it should make very little impact when updated,
> except for the occasional deprecation warnings and removal of legacy
> interfaces from public header files.  GCC is currently being tested
> weekly against Fedora rawhide and fixes for issues discovered are
> continually dropping into rawhide to minimize the impact on package
> maintainers.  However, we fully expect some issues to arise,
> particularly as the GCC team's tests are limited to x86_64.
> 
> * Release engineering:  [https://pagure.io/releng/issue/9858 9858] A
> mass rebuild is strongly encouraged.
> * Policies and guidelines: The policies and guidelines do not need to
> be updated.
> * Trademark approval: N/A (not needed for this Change)
> 
> == Upgrade/compatibility impact ==
> 
> 
> The compiler, and the the library are backwards compatible with the
> previous version of Fedora.
> 
> Some packaging changes may be required for the glibc 2.33 rebase:
> https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes
> 
> Some source changes may be required for gcc 11 rebase:
> https://gcc.gnu.org/gcc-11/changes.html
> 
> We fully expect to fix all packaging changes in Fedora Rawhide without
> impact to the release.
> 
> == How To Test ==
> The GNU C compiler collection has its own testsuite which is run
> during the package build and examined by the gcc developers before
> being uploaded.  The GCC team also is also doing continuous testing of
> GCC 11 snapshots against Fedora rawhide to identify and resolve issues
> prior to new versions of GCC landing in rawhide.  This work will
> continue, particularly in Nov, Dec, Jan and Feb and we will use it to
> help guide decisions about snapshots are stable enough to not cause
> major Fedora rawhide disruptions.  We expect that by March the pace of
> updates will reduce significantly.
> 
> The GCC team will likely need some help addressing some of the new
> diagnostics that require package specific knowledge to determine if
> the code is valid or not.  This is not new, but the timing will shift
> to earlier points in the Fedora release cycle.
> 
> The GNU C Library has its own testsuite, which is run during the
> package build and examined by the glibc developers before being
> uploaded. This test suite has over 

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

[Ben Cotton]

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

== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.

== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taym...@gmail.com


== Detailed Description ==
Currently, all desktop audio is handled by the PulseAudio daemon.
Applications make use of the
PulseAudio client library to communicate with the PulseAudio daemon
that mixes and manages the audio streams from the clients.

The desktop shell (gnome-shell) and the control panel
(gnome-control-panel) both use the
Pulseaudio client libraries to manage the volume and configuration of
the PulseAudio daemon.

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.

All PRO audio is handled with the JACK client library, which talks to
the JACK server. This
proposal will install a JACK client library replacement that talks
directly to PipeWire. All
existing PRO audio jack applications will then work on top of PipeWire.

For legacy ALSA clients, we will install an ALSA plugin that routes
the audio directly to
PipeWire.

With these 3 changes, all audio will be routed to PipeWire. There will
then be no more need to
install the PulseAudio and JACK daemons.

== Feedback ==
The owner of this proposal has been in context with both the
PulseAudio and JACK maintainers and community.
PipeWire is considered to be the successor of both projects.

== Benefit to Fedora ==
The end goal is to end up with one audio infrastructure for both
Desktop and Pro audio use cases.
This will end the fragmentation of the audio landscape.

Some of the benefits that PipeWire will bring:

 * PRO Audio features

   PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use
   the JACK API and JACK daemon, which is hard to setup and integrates
poorly with the rest of
   the system (and PulseAudio in particular).

   With a replacement libjack library, PRO Audio application can run
directly on PipeWire and
   integrate seamlessly with other ALSA and PulseAudio applications.
This would bring Fedora
   closer to the experience of other operating systems.

 * Flexibility/Integration

   PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph
   and the management into separate processes. This makes it possible
to better integrate with
   the other system components or swap out the default policy for a
highly customized one (such as
   for automotive or embedded). This is in contrast to PulseAudio,
which has all logic embedded
   into the daemon with limited configuration options.

   In the next phase we expect to greatly expand the user experience
and configuration of the
   audio infrastructure with better integration throughout the system.

 * Performance

   PipeWire was designed for high performance and low-latency, using
much of the same design as
   JACK. JACK application should run with comparable performance even
in low-latency situations.

 * Security

   PipeWire enforces per client security. Object visibility and the
actions on them can be
   configured independently per client. This makes it possible to
enforce a security policy for
   sandboxed applications (Flatpak) such as denying access to certain
audio capture devices or
   block them from interfering with other applications.

 * Maintainability

   Both PulseAudio and JACK have very slow development cycles with few
new features. The more
   flexible and distributed nature of the design of PipeWire should
encourage more new features
   and use-cases.

== Scope ==
* Proposal owners:
We would make a pipewire-pulse package that provides the same features
as the pulseaudio (daemon) package.
We would only provide a drop-in replacement daemon, the pulseaudio
client libraries will remain unchanged.

The idea is that when installing pipewire-pulse, only the pulseaudio
package is removed and replaced by the
pipewire-pulse implementation. In the same way, installing the
pulseaudio package would remove the pipewire-pulse
package, making it possible to switch between implementations. This
will also allow for an easy rollback.

We also need to check and correct the dependencies of other packages.
As of this writing, some packages do
not state their dependencies correctly and get removed when pulseaudio
is removed. We also need to check the
JACK to make sure they still install with the replacement JACK client library.

The JACK client libraries will be installed in the same way, removing
the old JACK client libraries.

* Other developers:
The distribution needs to default to the pipewire-pulse package
instead of pulseaudio.
JACK applications need to install the pipewire-libjack client library.

* Release engineering: 

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

[Ben Cotton]

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

== Summary ==
Switch the Fedora 33 GNU Toolchain to gcc 11, binutils 2.35, and glibc 2.33.

The binutils 2.35 change is being tracked here:
https://fedoraproject.org/wiki/Changes/BINUTILS235

The gcc 11 and glibc 2.33 change will be tracked in this top-level GNU
Toolchain system-wide update.

== Owner ==
* Name: [[User:codonell|Carlos O'Donell]], [[User:law|Jeff Law]]
* Email: car...@redhat.com, l...@redhat.com


== Detailed Description ==
The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities
make up the core part of the GNU Toolchain and it is useful to
transition these components as a complete implementation when making a
new release of Fedora.

The GNU Compiler Collection will be releasing version 11 containing
many new features documented here:
https://gcc.gnu.org/gcc-11/changes.html.  Historically pre-releases of
GCC drop into Fedora in Jan/Feb just prior to the mass rebuild.  The
major process change this year is the desire to drop in snapshots of
GCC 11 into rawhide starting in November with updates throughout the
Fedora 34 release process as needed.

The GNU C Library version 2.33 will be released at the beginning of
February 2020; we have started closely tracking the glibc 2.33
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 34 will branch after the
glibc 2.33 upstream release. However, the mass rebuild schedule means
Fedora 34 will mass rebuild (if required) after glibc 2.33 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.

== Benefit to Fedora ==
Stays up to date with latest features, improvements security and bug
fixes from gcc and glibc upstream.

The change to drop GCC 11 snapshots into rawhide earlier is meant to
start more wide scale testing of GCC earlier.  This means that package
maintainers will not be faced with a onslaught on FTBFS issues in
Feb/Mar and the GCC maintainers will not be as stressed trying to fix
all Fedora related issues in a short time frame as well.

== Scope ==
The gcc and glibc teams will need to move their respective upstream
projects to a releasable state.  For GCC this includes correctly
building Fedora rawhide.

* Other developers: Developers need to ensure that gcc, binutils, and
glibc in rawhide is stable and ready for the Fedora 34 branch. Given
that glibc is backwards compatible and we have been testing the new
glibc in rawhide it should make very little impact when updated,
except for the occasional deprecation warnings and removal of legacy
interfaces from public header files.  GCC is currently being tested
weekly against Fedora rawhide and fixes for issues discovered are
continually dropping into rawhide to minimize the impact on package
maintainers.  However, we fully expect some issues to arise,
particularly as the GCC team's tests are limited to x86_64.

* Release engineering:  [https://pagure.io/releng/issue/9858 9858] A
mass rebuild is strongly encouraged.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==


The compiler, and the the library are backwards compatible with the
previous version of Fedora.

Some packaging changes may be required for the glibc 2.33 rebase:
https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes

Some source changes may be required for gcc 11 rebase:
https://gcc.gnu.org/gcc-11/changes.html

We fully expect to fix all packaging changes in Fedora Rawhide without
impact to the release.

== How To Test ==
The GNU C compiler collection has its own testsuite which is run
during the package build and examined by the gcc developers before
being uploaded.  The GCC team also is also doing continuous testing of
GCC 11 snapshots against Fedora rawhide to identify and resolve issues
prior to new versions of GCC landing in rawhide.  This work will
continue, particularly in Nov, Dec, Jan and Feb and we will use it to
help guide decisions about snapshots are stable enough to not cause
major Fedora rawhide disruptions.  We expect that by March the pace of
updates will reduce significantly.

The GCC team will likely need some help addressing some of the new
diagnostics that require package specific knowledge to determine if
the code is valid or not.  This is not new, but the timing will shift
to earlier points in the Fedora release cycle.

The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future may also run the
microbenchmark to look for performance regressions.

== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc.

== Dependencies 

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

[Ben Cotton]

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

== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.

== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taym...@gmail.com


== Detailed Description ==
Currently, all desktop audio is handled by the PulseAudio daemon.
Applications make use of the
PulseAudio client library to communicate with the PulseAudio daemon
that mixes and manages the audio streams from the clients.

The desktop shell (gnome-shell) and the control panel
(gnome-control-panel) both use the
Pulseaudio client libraries to manage the volume and configuration of
the PulseAudio daemon.

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.

All PRO audio is handled with the JACK client library, which talks to
the JACK server. This
proposal will install a JACK client library replacement that talks
directly to PipeWire. All
existing PRO audio jack applications will then work on top of PipeWire.

For legacy ALSA clients, we will install an ALSA plugin that routes
the audio directly to
PipeWire.

With these 3 changes, all audio will be routed to PipeWire. There will
then be no more need to
install the PulseAudio and JACK daemons.

== Feedback ==
The owner of this proposal has been in context with both the
PulseAudio and JACK maintainers and community.
PipeWire is considered to be the successor of both projects.

== Benefit to Fedora ==
The end goal is to end up with one audio infrastructure for both
Desktop and Pro audio use cases.
This will end the fragmentation of the audio landscape.

Some of the benefits that PipeWire will bring:

 * PRO Audio features

   PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use
   the JACK API and JACK daemon, which is hard to setup and integrates
poorly with the rest of
   the system (and PulseAudio in particular).

   With a replacement libjack library, PRO Audio application can run
directly on PipeWire and
   integrate seamlessly with other ALSA and PulseAudio applications.
This would bring Fedora
   closer to the experience of other operating systems.

 * Flexibility/Integration

   PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph
   and the management into separate processes. This makes it possible
to better integrate with
   the other system components or swap out the default policy for a
highly customized one (such as
   for automotive or embedded). This is in contrast to PulseAudio,
which has all logic embedded
   into the daemon with limited configuration options.

   In the next phase we expect to greatly expand the user experience
and configuration of the
   audio infrastructure with better integration throughout the system.

 * Performance

   PipeWire was designed for high performance and low-latency, using
much of the same design as
   JACK. JACK application should run with comparable performance even
in low-latency situations.

 * Security

   PipeWire enforces per client security. Object visibility and the
actions on them can be
   configured independently per client. This makes it possible to
enforce a security policy for
   sandboxed applications (Flatpak) such as denying access to certain
audio capture devices or
   block them from interfering with other applications.

 * Maintainability

   Both PulseAudio and JACK have very slow development cycles with few
new features. The more
   flexible and distributed nature of the design of PipeWire should
encourage more new features
   and use-cases.

== Scope ==
* Proposal owners:
We would make a pipewire-pulse package that provides the same features
as the pulseaudio (daemon) package.
We would only provide a drop-in replacement daemon, the pulseaudio
client libraries will remain unchanged.

The idea is that when installing pipewire-pulse, only the pulseaudio
package is removed and replaced by the
pipewire-pulse implementation. In the same way, installing the
pulseaudio package would remove the pipewire-pulse
package, making it possible to switch between implementations. This
will also allow for an easy rollback.

We also need to check and correct the dependencies of other packages.
As of this writing, some packages do
not state their dependencies correctly and get removed when pulseaudio
is removed. We also need to check the
JACK to make sure they still install with the replacement JACK client library.

The JACK client libraries will be installed in the same way, removing
the old JACK client libraries.

* Other developers:
The distribution needs to default to the pipewire-pulse package
instead of pulseaudio.
JACK applications need to install the pipewire-libjack client library.

* Release engineering: 

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

[Ben Cotton]

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

== Summary ==
Switch the Fedora 33 GNU Toolchain to gcc 11, binutils 2.35, and glibc 2.33.

The binutils 2.35 change is being tracked here:
https://fedoraproject.org/wiki/Changes/BINUTILS235

The gcc 11 and glibc 2.33 change will be tracked in this top-level GNU
Toolchain system-wide update.

== Owner ==
* Name: [[User:codonell|Carlos O'Donell]], [[User:law|Jeff Law]]
* Email: car...@redhat.com, l...@redhat.com


== Detailed Description ==
The GNU Compiler Collection, GNU C Library, and GNU Binary Utilities
make up the core part of the GNU Toolchain and it is useful to
transition these components as a complete implementation when making a
new release of Fedora.

The GNU Compiler Collection will be releasing version 11 containing
many new features documented here:
https://gcc.gnu.org/gcc-11/changes.html.  Historically pre-releases of
GCC drop into Fedora in Jan/Feb just prior to the mass rebuild.  The
major process change this year is the desire to drop in snapshots of
GCC 11 into rawhide starting in November with updates throughout the
Fedora 34 release process as needed.

The GNU C Library version 2.33 will be released at the beginning of
February 2020; we have started closely tracking the glibc 2.33
development code in Fedora Rawhide and are addressing any issues as
they arise. Given the present schedule Fedora 34 will branch after the
glibc 2.33 upstream release. However, the mass rebuild schedule means
Fedora 34 will mass rebuild (if required) after glibc 2.33 upstream
freezes ABI for release, but before the actual release, so careful
attention must be paid to any last minute ABI changes.

== Benefit to Fedora ==
Stays up to date with latest features, improvements security and bug
fixes from gcc and glibc upstream.

The change to drop GCC 11 snapshots into rawhide earlier is meant to
start more wide scale testing of GCC earlier.  This means that package
maintainers will not be faced with a onslaught on FTBFS issues in
Feb/Mar and the GCC maintainers will not be as stressed trying to fix
all Fedora related issues in a short time frame as well.

== Scope ==
The gcc and glibc teams will need to move their respective upstream
projects to a releasable state.  For GCC this includes correctly
building Fedora rawhide.

* Other developers: Developers need to ensure that gcc, binutils, and
glibc in rawhide is stable and ready for the Fedora 34 branch. Given
that glibc is backwards compatible and we have been testing the new
glibc in rawhide it should make very little impact when updated,
except for the occasional deprecation warnings and removal of legacy
interfaces from public header files.  GCC is currently being tested
weekly against Fedora rawhide and fixes for issues discovered are
continually dropping into rawhide to minimize the impact on package
maintainers.  However, we fully expect some issues to arise,
particularly as the GCC team's tests are limited to x86_64.

* Release engineering:  [https://pagure.io/releng/issue/9858 9858] A
mass rebuild is strongly encouraged.
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==


The compiler, and the the library are backwards compatible with the
previous version of Fedora.

Some packaging changes may be required for the glibc 2.33 rebase:
https://sourceware.org/glibc/wiki/Release/2.33#Packaging_Changes

Some source changes may be required for gcc 11 rebase:
https://gcc.gnu.org/gcc-11/changes.html

We fully expect to fix all packaging changes in Fedora Rawhide without
impact to the release.

== How To Test ==
The GNU C compiler collection has its own testsuite which is run
during the package build and examined by the gcc developers before
being uploaded.  The GCC team also is also doing continuous testing of
GCC 11 snapshots against Fedora rawhide to identify and resolve issues
prior to new versions of GCC landing in rawhide.  This work will
continue, particularly in Nov, Dec, Jan and Feb and we will use it to
help guide decisions about snapshots are stable enough to not cause
major Fedora rawhide disruptions.  We expect that by March the pace of
updates will reduce significantly.

The GCC team will likely need some help addressing some of the new
diagnostics that require package specific knowledge to determine if
the code is valid or not.  This is not new, but the timing will shift
to earlier points in the Fedora release cycle.

The GNU C Library has its own testsuite, which is run during the
package build and examined by the glibc developers before being
uploaded. This test suite has over 6200 tests that run to verify the
correct operation of the library. In the future may also run the
microbenchmark to look for performance regressions.

== User Experience ==
Users will see improved performance, many bugfixes and improvements to
POSIX compliance, additional locales, etc.

== Dependencies 

Re: video meeting to discuss Matrix/Element and IRC

[Matthew Miller]

On Fri, Nov 20, 2020 at 08:44:32AM +0100, Vitaly Zaitsev via devel wrote:
> >In this case for our server, we would use FAS single-sign-on for
> >accounts.
> But this server should support Matrix federation feature. We
> shouldn't force users to use only this server in order to be able to
> participate in discussions. I already have my own Matrix server.

Yes, I don't see why not. As I understand it, if your server becomes a
source of spam or whatever, we can block it. But I trust that it won't. :)


-- 
Matthew Miller

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

Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

[Matthew Miller]

On Fri, Nov 20, 2020 at 12:03:27AM +0100, Emmanuel Seyman wrote:
> I suspect that these packages are maintained only to the point where they
> can build (and thus be used as buildreqs) but their maintainer also doesn't
> want them to be updated without making sure that the update will not break
> the package they are really interested in.

That's probably also true. So communicating that reverse-dependency might be
another important aspect. CI gating should in theory help here.

> What exactly do you want to do with this list of lightly-maintained packages?
> 
> Is this something you want to present to end-users?

Yes.

> Is this a list we should show to people tempted to become packagers?

Possibly? Maybe more appropriate for packagers interested in increasing
overall packaging quality.

> Do we want to generate auto-replies to bugs filed in Bugzilla?

Yes, I think so. Explaining the situation and asking for help. We may also
want to have a process for making sure that bugs which actually might
percolate up to the actual package of interest don't get discarded. 


> Should SIGs keep a lookout for security fixes to apply?

That would be awesome in general, I think.


-- 
Matthew Miller

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

[Bug 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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



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


-- 
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 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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



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


-- 
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 1900029] New: perl-Moo-2.004002 is available

[bugzilla]

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

Bug ID: 1900029
   Summary: perl-Moo-2.004002 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Moo
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.004002
Current version/release in rawhide: 2.004000-3.fc33
URL: http://search.cpan.org/dist/Moo/

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


-- 
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 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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



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


-- 
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 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Module-CoreList-5.2020
   ||1120-1.fc34



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.


-- 
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 1899994] perl-Module-CoreList-5.20201120 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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 1899984] perl-Devel-PatchPerl-2.04 is available

[bugzilla]

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



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


-- 
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 1899984] perl-Devel-PatchPerl-2.04 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Devel-PatchPerl-2.04-1
   ||.fc34



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 33.


-- 
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 1899971] perl-CPAN-Perl-Releases-5.20201120 is available

[bugzilla]

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



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


-- 
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 1899984] perl-Devel-PatchPerl-2.04 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




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

[bugzilla]

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



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


-- 
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 1899971] perl-CPAN-Perl-Releases-5.20201120 is available

[bugzilla]

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



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


-- 
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: Mock needs more space

[Brandon Nielsen]

On 11/20/20 2:03 AM, Pavel Raiskup wrote:

On Friday, November 20, 2020 2:42:08 AM CET Brandon Nielsen wrote:

I'm attempting an armhfp build with mock and it insists it needs "At
least 243MB more space needed on the / filesystem."


This seems to be a bug in RPM:
https://bugzilla.redhat.com/show_bug.cgi?id=1895363

Work-around is to disable bootstrap in that particular chroot.

Pavel


I have 1.1 TB free on /, so I'm assuming there's some kind of limit set
somehow, but I can't figure out how to adjust it. I don't see anything
that looks promising in the config files, or the manpage. Anybody have a
clue for me?


I can confirm, passing '--no-bootstrap-chroot' works around the issue. 
Thank you so much!

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1899971] perl-CPAN-Perl-Releases-5.20201120 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-CPAN-Perl-Releases-5.2
   ||0201120-1.fc34



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.


-- 
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 1899971] perl-CPAN-Perl-Releases-5.20201120 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




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

Fedora 31 End Of Life

[Mohan Boddu]

Hello all,

Fedora 31 will go end of life for updates and support on 24th of
November 2020. No further updates, including security updates, will be
available for Fedora 31 after the said date. All the updates of Fedora
31 being pushed to stable will be stopped as well.

Fedora 32 will continue to receive updates until approximately one
month after the release of Fedora 34. The maintenance schedule of
Fedora releases is documented on the Fedora Project wiki [0]. The
fedora Project wiki also contains instructions [1] on how to upgrade
from a previous release of Fedora to a version receiving updates.

Regards,
Mohan Boddu.

[0]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
___
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

Fedora 31 End Of Life

[Mohan Boddu]

Hello all,

Fedora 31 will go end of life for updates and support on 24th of
November 2020. No further updates, including security updates, will be
available for Fedora 31 after the said date. All the updates of Fedora
31 being pushed to stable will be stopped as well.

Fedora 32 will continue to receive updates until approximately one
month after the release of Fedora 34. The maintenance schedule of
Fedora releases is documented on the Fedora Project wiki [0]. The
fedora Project wiki also contains instructions [1] on how to upgrade
from a previous release of Fedora to a version receiving updates.

Regards,
Mohan Boddu.

[0]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[1]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: systemd-resolved in a container

[Daniel Walsh]

On 11/19/20 03:06, Nikos Mavrogiannopoulos wrote:

On Wed, Nov 18, 2020 at 2:23 PM Alexander Bokovoy  wrote:

On ke, 18 marras 2020, Nikos Mavrogiannopoulos wrote:

Hi,
I realized my fedora-based containers have an /etc/resolv.conf which
claims it is managed by resolved, and nsswitch.conf has "resolve" in
hosts. However, doing something like
# systemd-resolve  --status

results to:
sd_bus_open_system: No such file or directory

Trying to start dbus claims that systemd is not the init:
# systemctl start dbus
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down


Is there a way to use systemd resolved in a container?

I figured this out yesterday -- at least in Rawhide, dbus-daemon is now
replaced by dbus-broker which is not active by default.

So you need

   systemctl enable --now dbus-broker

Without it even hostnamectl doesn't work, not just systemd-resolve.

Is that on the "default" fedora container, or do you use something
else? On fedora33 I get the same message about dbus and systemd not
being pid 1.

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


I was mistaken, there is no fedora-init image. There is a ubi8-init image.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1899994] New: perl-Module-CoreList-5.20201120 is available

[bugzilla]

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

Bug ID: 184
   Summary: perl-Module-CoreList-5.20201120 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Module-CoreList
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org, spo...@gmail.com,
st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 5.20201120
Current version/release in rawhide: 5.20201020-1.fc34
URL: http://search.cpan.org/dist/Module-CoreList/

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


-- 
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 1899984] New: perl-Devel-PatchPerl-2.04 is available

[bugzilla]

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

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



Latest upstream release: 2.04
Current version/release in rawhide: 2.02-1.fc34
URL: http://search.cpan.org/dist/Devel-PatchPerl/

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


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

[389-devel] please review: PR 4450 - Use MONOTONIC clock for all timing events and timed condition vars

[Mark Reynolds]

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

--

389 Directory Server Development Team
___
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

[Bug 1899971] New: perl-CPAN-Perl-Releases-5.20201120 is available

[bugzilla]

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

Bug ID: 1899971
   Summary: perl-CPAN-Perl-Releases-5.20201120 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-Perl-Releases
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 5.20201120
Current version/release in rawhide: 5.20201020-1.fc34
URL: http://search.cpan.org/dist/CPAN-Perl-Releases/

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


-- 
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: video meeting to discuss Matrix/Element and IRC

[Simo Sorce]

On Thu, 2020-11-19 at 23:14 -0500, Matthew Miller wrote:
> On Fri, Nov 20, 2020 at 02:06:46AM +0100, Dominik 'Rathann' Mierzejewski 
> wrote:
> > > > No, you don't. I've just joined a random room without any kind of
> > > > registration. Try it yourself if you don't believe me:
> > > > https://app.element.io/#/room/#lounge:privacytools.io
> > > You are able to view it but are you able to participate?  If not, you
> > > haven't joined
> > I know the difference and yes, you're able to participate without
> > registration in that room.
> 
> When I view this room in a private browser window, I can see the
> conversation, but at the bottom, it says "Join the conversation with an
> account" and presents "Sign In" / "Sign Up" buttons.

Good for you, this is what I got:

   Failed to start
   Your Element is misconfigured

   Invalid homeserver discovery response

Sounds like if you already are a user it works, otherwise not

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Summary/Minutes from today's FESCo Meeting (2020-11-11)

[Vitaly Zaitsev via devel]

On 20.11.2020 13:58, Stephen John Smoogen wrote:
We have a lot of packages who are only maintained in the sense that it 
was orphaned and someone realized that some other package needed it. Yes 
there are some packages which have not had an update because the 
upstream feels the package is done.. we have other code that is slow 
updating.. and a lot of other excuses of 'not all packages' when this 
topic gets brought up. However start saying 'ok let's count how many are 
like that' and people skitter off fast.


If the "lightly-maintained packages" will be allowed, more and more 
packagers will ditch their header-only libraries and move into this 
repo. This is not good, because many people use them not only for 
building packages, but also for the development.


I maintain a lot of such header-only packages.

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

Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

[Stephen John Smoogen]

On Fri, 20 Nov 2020 at 02:58, Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:

> On 19.11.2020 23:13, Matthew Miller wrote:
> > Some packagers in Fedora do not have time to maintain the build
> dependencies
> > for the packages that they are actually interested in and have time to
> > build.
>
> By allowing such packages, we will open the Pandora's box. Most of them
> will never receive updates and will have known bugs and security
> vulnerabilities. As a result, the packages that will use them will also
> be vulnerable.
>
> That's why I'm strongly against this proposal. All packages must be
> equally maintained.
>
>
Packages are NOT all equally maintained. They haven't been for years. There
are not enough active packagers to equally maintain the ~23000 (22446
regular + 657 module srcrpms) packages in rawhide. We have a lot of
packages who are only maintained in the sense that it was orphaned and
someone realized that some other package needed it. Yes there are some
packages which have not had an update because the upstream feels the
package is done.. we have other code that is slow updating.. and a lot of
other excuses of 'not all packages' when this topic gets brought up.
However start saying 'ok let's count how many are like that' and people
skitter off fast.

I get it. No one wants to look at the basement or attic and clean it up..
doesn't matter how many rats are in it from the buildup. just put out more
traps in the places we live and its fine.

[To be clear I am not for sticking packages in a attic repository. I am for
admitting we have a lot of closets and probably a basement of little
maintained packages, we have stuck things in it one way or another, and we
can either clean up the mess or get rid of it.]




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


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: video meeting to discuss Matrix/Element and IRC

[Vitaly Zaitsev via devel]

On 20.11.2020 10:46, Dominik 'Rathann' Mierzejewski wrote:

How does a server become federated?


You need to open port 8448/tcp and add an SRV DNS record:

_matrix._tcp.example.org. 3600 IN SRV 10 0 8448 example.org.

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

Re: own matrix server

[Vitaly Zaitsev via devel]

On 20.11.2020 11:22, Marius Schwarz wrote:

Which one do you use?


Synapse.


Any problems setting it up?


No. It just works.

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

[Bug 1899767] perl-HTTP-Cookies-6.09 is available

[bugzilla]

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



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


-- 
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 1899767] perl-HTTP-Cookies-6.09 is available

[bugzilla]

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



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


-- 
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 1899531] perl-Convert-Binary-C-0.83 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Convert-Binary-C-0.83-
   ||1.fc34
 Resolution|--- |RAWHIDE
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-11-20 11:04:53




-- 
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 1899767] perl-HTTP-Cookies-6.09 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-HTTP-Cookies-6.09-1.fc
   ||34



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 32


-- 
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 1899731] perl-ExtUtils-MakeMaker-7.56 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-ExtUtils-MakeMaker-7.5
   ||6-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2020-11-20 10:57:30



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 34.


-- 
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 1899767] perl-HTTP-Cookies-6.09 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




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

Fedora-Cloud-31-20201120.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

[Bug 1899731] perl-ExtUtils-MakeMaker-7.56 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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: video meeting to discuss Matrix/Element and IRC

[Marius Schwarz]

Am 19.11.20 um 21:13 schrieb José Abílio Matos:


On Thursday, November 19, 2020 5:54:52 PM WET Richard W.M. Jones wrote:

> I'm not sure that message editing is a feature.


In fairness as long as the grace period is fixed and small that is not 
a bad thing.


E.g it allows you to fix lots of cases where you found that the 
message was incomplete after sending it or it had incorrect 
information that you only found after sending it.



That allows to clean some noise and it is not a bad thing. :-)

--




Just imagine to fix a typo in a cmd you gave as advise.. it's very usefull.

Best regards,
Marius

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

own matrix server

[Marius Schwarz]

Hi,

But this server should support Matrix federation feature. We shouldn't 
force users to use only this server in order to be able to participate 
in discussions. I already have my own Matrix server.




Which one do you use?

Any problems setting it up?


Best regards,
Marius
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: video meeting to discuss Matrix/Element and IRC

[Marius Schwarz]

Am 19.11.20 um 23:42 schrieb Adam Williamson:

The chat history persistence - and seamless use across devices - is a
huge advantage. The other advantage is that you can sign up for and use
this system simply and entirely in a web browser, a process people are
comfortable with. It is similar to systems they may well already be
familiar with, like Slack and Discord. People are not comfortable with
Discord is the best example on how to not have an age old history. If 
you have joined only one of those, you get blinded by blinking 
emotiocons, animgifs  etc.


That is the opposite of helpful while discussing important things. In a 
Hello Kitty context, as entertainment, it may have it's usecase for 
those impacted.


It would be helpful, if the serveradmin hosting a matrix room can 
deactivate those useless distractions.


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

[Bug 1899556] perl-PDL-2.025 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-PDL-2.25.0-1.fc34
 Resolution|--- |RAWHIDE
Last Closed||2020-11-20 10:11:44




-- 
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: video meeting to discuss Matrix/Element and IRC

[Dominik 'Rathann' Mierzejewski]

On Friday, 20 November 2020 at 08:41, Vitaly Zaitsev via devel wrote:
> On 20.11.2020 02:06, Dominik 'Rathann' Mierzejewski wrote:
> > I know the difference and yes, you're able to participate without
> > registration in that room.
> 
> There are free levels of privacy settings:
> 1. join via invitation;
> 2. public group with guests;
> 3. public room without guests.

So, just like IRC. IRC also has invite-only channels with or without
guests.

> Most of rooms keep guests feature disabled due to spam attacks. You will
> need a Matrix account on any federated server to be able to join.

How does a server become federated? Is setting up synapse service
and specifying a domain name in its config all[1]? If yes, does that
mean anyone can set up a server and will be joined automatically to the
existing network? I tried searching the documentation, but I couldn't
find anything about how malicious homeservers are treated.

[1] https://github.com/matrix-org/synapse/blob/master/docs/federate.md

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-Cloud-32-20201120.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-32-20201119.0):

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

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: Mock needs more space

[Dominik 'Rathann' Mierzejewski]

On Friday, 20 November 2020 at 09:03, Pavel Raiskup wrote:
> On Friday, November 20, 2020 2:42:08 AM CET Brandon Nielsen wrote:
> > I'm attempting an armhfp build with mock and it insists it needs "At 
> > least 243MB more space needed on the / filesystem."
> 
> This seems to be a bug in RPM:
> https://bugzilla.redhat.com/show_bug.cgi?id=1895363
> 
> Work-around is to disable bootstrap in that particular chroot.

I hit that one a couple of days ago as well and found the same
work-around. Thanks for opening the bug. I added myself to Cc.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 in GCP

[Ondrej Budai]

pá 20. 11. 2020 v 1:43 odesílatel Dusty Mabe  napsal:

> We have published an image into GCP for Fedora 33 (see [1]).
>
> The details are:
>
> image project: fedora-cloud
> image name:fedora-cloud-base-gcp-33-1-2-x86-64
>
> We're hoping to get this information added to the website at some point.
>
> Dusty
>
> [1] https://pagure.io/cloud-sig/issue/318
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


Hello! I work on the Image Builder project[1]. We do support uploading
Fedora images to AWS and Azure and we would love to get support for GCP.
Can you point me at some resources on how Fedora images are built for GCP
and how they are uploaded/registered?

Thanks!

Cheers,

Ondřej

[1] https://www.osbuild.org/

-- 

Ondřej Budai

Software Engineer

Red Hat 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Mock needs more space

[Pavel Raiskup]

On Friday, November 20, 2020 2:42:08 AM CET Brandon Nielsen wrote:
> I'm attempting an armhfp build with mock and it insists it needs "At 
> least 243MB more space needed on the / filesystem."

This seems to be a bug in RPM:
https://bugzilla.redhat.com/show_bug.cgi?id=1895363

Work-around is to disable bootstrap in that particular chroot.

Pavel

> I have 1.1 TB free on /, so I'm assuming there's some kind of limit set 
> somehow, but I can't figure out how to adjust it. I don't see anything 
> that looks promising in the config files, or the manpage. Anybody have a 
> clue for me?
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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