Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Zdenek Dohnal]

On 4/14/20 9:23 PM, Ben Cotton wrote:
> === Multicast DNS ===
>
> systemd-resolved's multicast DNS support conflicts with Avahi. Per
> recommendation from the systemd developers, we will change the default
> value of this setting in Fedora from the upstream default
> `MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving
> will be enabled, but responding will be disabled. This will require
> adding a new systemd build option to control the default value of the
> MulticastDNS setting, similar to the existing `default-dnssec` and
> `default-dns-over-tls` build options.
>
>
Hi Michael,

would you mind telling me more about the change's impact on MDNS support
provided by Avahi and nss-mdns package, since you mention Avahi
conflicts with systemd-resolved?

CUPS relies on Avahi/nss-mdns for its MDNS functionality (resolving MDNS
addresses, browsing services, registering services...) because it is
essential for automatic printer discovery and driverless printing
functionality, which is supported by devices since 2010.

According https://github.com/apple/cups/issues/5452 systemd-resolved was
not the replacement for Avahi at the time, so is there a way how to make
Avahi work with the change, hopefully as default?

Non-working MDNS via Avahi would put us back in <2010.

Thank you in advance for response!

Zdenek

-- 
Zdenek Dohnal
Software Engineer
Red Hat Czech - Brno TPB-C




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

[Test-Announce] Fedora 32 Candidate RC-1.3 Available Now!

[rawhide]

According to the schedule [1], Fedora 32 Candidate RC-1.3 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.3_Security_Lab

All RC priority test cases for each of these test pages [2] must
pass in order to meet the RC Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-32/f-32-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_32_RC_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
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 33 System-Wide Change proposal: systemd-resolved

[Pavel Raiskup]

On Tuesday, April 14, 2020 9:23:27 PM CEST Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/systemd-resolved
> 
> == Summary ==
> 
> Enable systemd-resolved by default. ...

We had serious headaches because racy systemd-resolved got enabled for
some unknown reasons on copr builders before (and my host as well, for
example).  I filled bug [1] and then I was told that nobody
tests/maintains systemd-resolved... why on earth I'd opt-in to use that.

Can we fix the bug, so the generated resolv.conf pointing to local server
does work _immediately_ inside mock, and isn't it port-triggered (or what
it is :-))?

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

Pavel


___
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 System-Wide Change proposal: systemd-resolved

[stan via devel]

On Tue, 14 Apr 2020 18:39:05 -0500
Michael Catanzaro  wrote:

> On Tue, Apr 14, 2020 at 3:52 pm, stan via devel 
>  wrote:
> > Will the ability to turn off NetworkManager involvement in DNS in
> > the configuration file (None) still remain?  I use a local caching
> > DNS server, and had to do that in order to allow it to run without
> > interference / override by NetworkManager.  
> 
> Of course. You just have to set dns=None in your 
> /etc/NetworkManager.conf, as before. Also: 'systemctl disable 
> systemd-resolved.service'.

Excellent!  Thanks.
___
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 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Apr 14, 2020 at 3:52 pm, stan via devel 
 wrote:

Will the ability to turn off NetworkManager involvement in DNS in the
configuration file (None) still remain?  I use a local caching DNS
server, and had to do that in order to allow it to run without
interference / override by NetworkManager.


Of course. You just have to set dns=None in your 
/etc/NetworkManager.conf, as before. Also: 'systemctl disable 
systemd-resolved.service'.


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

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[stan via devel]

On Tue, 14 Apr 2020 15:52:55 -0700
stan via devel  wrote:

> On Tue, 14 Apr 2020 16:18:02 -0500
> Michael Catanzaro  wrote:
>  
> > NetworkManager has three DNS backends: default (nss-dns, what we
> > use currently), dnsmasq, and systemd-resolved. The default backend
> > just does the wrong thing and cannot be fixed. When either dnsmasq
> > or systemd-resolved is in use, NetworkManager will go ahead and do
> > the right thing by telling dnsmasq/systemd-resolved which network 
> > interfaces should be used to resolve which hostnames. I consulted
> > with the NetworkManager developers and they recommended
> > systemd-resolved over dnsmasq, although I understand that dnsmasq is
> > good too.  
> 
> Will the ability to turn off NetworkManager involvement in DNS in the
> configuration file (None) still remain?  I use a local caching DNS
> server, and had to do that in order to allow it to run without
> interference / override by NetworkManager.

Just a further note.  I tried both dnsmasq and systemd-resolved, but
neither seemed to work.  I still saw my browser saying 
Looking up blah-blah.com ...
and timing for seconds even if I just visited the page a few minutes
before.  Once I set up my own caching DNS server, that went away except
when I visit a new site.
___
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

[Test-Announce] Re: Fedora 32 Candidate RC-1.2 Available Now!

[Adam Williamson]

On Tue, 2020-04-14 at 15:35 +, rawh...@fedoraproject.org wrote:
> According to the schedule [1], Fedora 32 Candidate RC-1.2 is now
> available for testing. Please help us complete all the validation
> testing! For more information on release validation testing, see:
> https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Hey folks!

So just to make sure everyone is aware: there turned out to be a couple
of blockers in RC 1.2 plus several FEs we threw in, and an RC 1.3 is
brewing right now. It should be available for testing in a few hours.
It's still worth trying to find any critical errors in RC 1.2, and
report any you do find, but please be ready to test RC 1.3 when it
shows up too. 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 33 System-Wide Change proposal: systemd-resolved

[stan via devel]

On Tue, 14 Apr 2020 16:18:02 -0500
Michael Catanzaro  wrote:
 
> NetworkManager has three DNS backends: default (nss-dns, what we use 
> currently), dnsmasq, and systemd-resolved. The default backend just 
> does the wrong thing and cannot be fixed. When either dnsmasq or 
> systemd-resolved is in use, NetworkManager will go ahead and do the 
> right thing by telling dnsmasq/systemd-resolved which network 
> interfaces should be used to resolve which hostnames. I consulted
> with the NetworkManager developers and they recommended
> systemd-resolved over dnsmasq, although I understand that dnsmasq is
> good too.

Will the ability to turn off NetworkManager involvement in DNS in the
configuration file (None) still remain?  I use a local caching DNS
server, and had to do that in order to allow it to run without
interference / override by NetworkManager.
___
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: pagure ssh key

[Samuel Sieb]

On 4/14/20 2:25 PM, Aleksei Bavshin wrote:

SSH access to src.fp.o is limited to packagers. However you can push
to your fork via http as described here:
https://docs.fedoraproject.org/en-US/ci/pull-requests/


Thank you, that works.
___
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

[Test-Announce] [Test Day] Fedora 32 IoT Test Day is *TODAY*

[Sumantro Mukherjee]

Hey Testers!

As many of you know the Fedora 32 cycle is approaching a Final Freeze,
Fedora IoT and QA Team are hosting Fedora 32  IoT Test Day[0], which
is under way and you can start landing your first Fedora QA
contribution by participating in the Fedora IoT Test Day.
The steps are simple and outlined in the wiki[1] and the results can
be submitted here[2]

As always, we hang around #fedora-test-day and #fedora-qa to answer
general questions.

[0] 
https://communityblog.fedoraproject.org/contribute-at-the-fedora-32-iot-edition-test-day-2/
[1] https://fedoraproject.org/wiki/Test_Day:2020-04-15_Fedora_32_IoT_Edition
[2] http://testdays.fedorainfracloud.org/events/83

Thanks
-- 
//sumantro
Fedora QE
TRIED AND PERSONALLY TESTED, ERGO TRUSTED
___
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 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek 
 wrote:

I guess the lesson here is the nsswitch.conf change should be
clarified in the proposal.


OK, I've just added it at the end of this part here:

"systemd-libs currently has 
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede5d234b7878753/f/systemd.spec#_606 
a %post scriplet] to enable nss-myhostname and nss-systemd by either 
(a) modifying authselect's user-nsswitch.conf template, if authselect 
is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We 
will work with the systemd maintainers to enable nss-resolve here as 
well by adding `resolve [!UNAVAIL=return]` to the hosts line."


Then the instructions in the change proposal for disabling 
systemd-resolved say:


"Modify /etc/authselect/user-nsswitch.conf and remove resolve 
[!UNAVAIL=return] from the hosts line. Run authselect apply-changes. 
(If you have disabled authselect, then edit /etc/nsswitch.conf 
directly.)"


I guess I should delete that from the proposal, since it's not needed?


I'm not sure what the best path option here is. The path of least
resistance would be to simply leave /etc/resolv.conf out of this 
change.

nss-resolve doesn't care, and the effect is only on things which
don't use the nss stack, or read /etc/resolv.conf for other purposes.


NetworkManager only enables its systemd-resolved backend if 
/etc/resolv.conf is symlinked appropriately. So that needs to happen.


I didn't consider cases where systemd is not running because Fedora 
hasn't supported booting without systemd in about a decade. But I guess 
the problem here is for containers where systemd is not running inside 
the container, but is running on the host system? I hadn't considered 
this scenario. What do Ubuntu containers do? I guess those are not all 
broken. :)


___
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: pagure ssh key

[Aleksei Bavshin]

Hi Samuel,

SSH access to src.fp.o is limited to packagers. However you can push
to your fork via http as described here:
https://docs.fedoraproject.org/en-US/ci/pull-requests/

On Tue, Apr 14, 2020 at 2:15 PM Samuel Sieb  wrote:
>
> I'm wanting to make a pull request on src.fedoraproject.org, so I need
> to setup an ssh key.  According to the docs at
> https://docs.pagure.org/pagure/usage/first_steps.html, there should be
> an authentication section in my settings, but there isn't.  Then I
> remembered that I added an ssh public key to my FAS profile on
> admin.fedoraproject.org.  I checked that and it's valid and matches my
> key.  I've given it some time (hours) in case there's some delay needed
> after forking.  However, I'm still getting an authentication error when
> trying to clone using git over ssh.
> ss...@pkgs.fedoraproject.org: Permission denied (publickey)
>
> Is there something I'm missing?  I'm not a packager, but I have a FAS
> account and it let me fork the repo.
> ___
> 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



-- 
With best regards,
Aleksei Bavshin
___
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 System-Wide Change proposal: systemd-resolved

[Adam Williamson]

On Tue, 2020-04-14 at 16:18 -0500, Michael Catanzaro wrote:
> On Tue, Apr 14, 2020 at 12:45 pm, Adam Williamson 
>  wrote:
> > Doesn't NetworkManager already broadly address both of these on all
> > installations where it's used (which is all Fedora installs by
> > default)?
> 
> I don't think so, no.
> 
> As far as I know, NetworkManager does not have a DNS cache. The only 
> way to implement one systemwide would be to write a glibc NSS plugin. 
> Otherwise, how would glibc be able to talk to NetworkManager to use the 
> cached results?

> Then the description of multi-VPN scenario is written based on the 
> status quo with NetworkManager already installed and enabled. 
> NetworkManager has three DNS backends: default (nss-dns, what we use 
> currently), dnsmasq, and systemd-resolved. The default backend just 
> does the wrong thing and cannot be fixed. When either dnsmasq or 
> systemd-resolved is in use, NetworkManager will go ahead and do the 
> right thing by telling dnsmasq/systemd-resolved which network 
> interfaces should be used to resolve which hostnames. I consulted with 
> the NetworkManager developers and they recommended systemd-resolved 
> over dnsmasq, although I understand that dnsmasq is good too.

I thought we'd made the dnsmasq config default at some point (that
implements both caching and split DNS). I guess I was remembering
wrong.
-- 
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: pagure ssh key

[Jorge Gallegos]

On Tue, Apr 14, 2020 at 02:14:40PM -0700, Samuel Sieb wrote:
> I'm wanting to make a pull request on src.fedoraproject.org, so I need to
> setup an ssh key.  According to the docs at
> https://docs.pagure.org/pagure/usage/first_steps.html, there should be an
> authentication section in my settings, but there isn't.  Then I remembered
> that I added an ssh public key to my FAS profile on admin.fedoraproject.org.
> I checked that and it's valid and matches my key.  I've given it some time
> (hours) in case there's some delay needed after forking.  However, I'm still
> getting an authentication error when trying to clone using git over ssh.
> ss...@pkgs.fedoraproject.org: Permission denied (publickey)
> 
> Is there something I'm missing?  I'm not a packager, but I have a FAS
> account and it let me fork the repo.
> ___
> 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

Hi Samuel,

What happens if you go to https://pagure.io/settings#nav-ssh-tab while
logged in with your FAS account in pagure?


Cheers,

-- 
I can resist anything but temptation.


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: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Apr 14, 2020 at 12:45 pm, Adam Williamson 
 wrote:

Doesn't NetworkManager already broadly address both of these on all
installations where it's used (which is all Fedora installs by
default)?


I don't think so, no.

As far as I know, NetworkManager does not have a DNS cache. The only 
way to implement one systemwide would be to write a glibc NSS plugin. 
Otherwise, how would glibc be able to talk to NetworkManager to use the 
cached results?


Then the description of multi-VPN scenario is written based on the 
status quo with NetworkManager already installed and enabled. 
NetworkManager has three DNS backends: default (nss-dns, what we use 
currently), dnsmasq, and systemd-resolved. The default backend just 
does the wrong thing and cannot be fixed. When either dnsmasq or 
systemd-resolved is in use, NetworkManager will go ahead and do the 
right thing by telling dnsmasq/systemd-resolved which network 
interfaces should be used to resolve which hostnames. I consulted with 
the NetworkManager developers and they recommended systemd-resolved 
over dnsmasq, although I understand that dnsmasq is good too.


Michael

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

Fedora-IoT-33-20200414.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd aarch64
Iot dvd x86_64

Failed openQA tests: 1/8 (x86_64)

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

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

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

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

ID: 577002  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/577002
ID: 577003  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/577003

Passed openQA tests: 5/8 (x86_64)

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Used mem changed from 159 MiB to 135 MiB
Previous test data: https://openqa.fedoraproject.org/tests/575423#downloads
Current test data: https://openqa.fedoraproject.org/tests/577002#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 158 MiB to 136 MiB
Peak task count changed from 125 to 105
Previous test data: https://openqa.fedoraproject.org/tests/575424#downloads
Current test data: https://openqa.fedoraproject.org/tests/577003#downloads
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

pagure ssh key

[Samuel Sieb]

I'm wanting to make a pull request on src.fedoraproject.org, so I need 
to setup an ssh key.  According to the docs at 
https://docs.pagure.org/pagure/usage/first_steps.html, there should be 
an authentication section in my settings, but there isn't.  Then I 
remembered that I added an ssh public key to my FAS profile on 
admin.fedoraproject.org.  I checked that and it's valid and matches my 
key.  I've given it some time (hours) in case there's some delay needed 
after forking.  However, I'm still getting an authentication error when 
trying to clone using git over ssh.

ss...@pkgs.fedoraproject.org: Permission denied (publickey)

Is there something I'm missing?  I'm not a packager, but I have a FAS 
account and it let me fork the repo.

___
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 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Apr 14, 2020 at 12:57 pm, Kevin Fenzi  wrote:

Can you expand on what that means?

Does it mean:

a) systemd-resolved will use DNS over TLS if it detects that
the nameservers it is querying can do so (ie, it would do a query to
port 853 of the nameservers dhcp or static config gave it)

b) systemd-resolved will use DNS over TLS and always use some 'well
known' public dns servers for queries, ignoring locally configured
servers.

I'm very much in favor of a, but not in favor of b. :)


It would do (a). (But as part of a future change, not part of this 
change.)


I think (b) would be too controversial for Fedora.

 That said, there are not currently any known compatibility problems 
with the
 DNS over TLS support as far as I know, so I would *expect* it to go 
smoothly

 regardless.

 Of course, once systemd-resolved is enabled, then enabling or 
disabling DNS

 over TLS will be a one-line config file change in
 /etc/systemd/resolved.conf. :)


Is that going to be to set it to 'opportunistic' or 'true' ?


It would be "opportunistic". (But again, that would be a future change, 
not this change.)


___
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 System-Wide Change proposal: systemd-resolved

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 14, 2020 at 03:57:50PM -0400, James Cassell wrote:
> 
> On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/systemd-resolved
> > 
> > == Summary ==
> > 
> > Enable systemd-resolved by default. glibc will perform name resolution
> > using nss-resolve rather than nss-dns.
> > 
> > == Owner ==
> > * Name: [[User:catanzaro| Michael Catanzaro]]
> > * Email: 
> > 
> > == Detailed Description ==
> > 
> > We will enable systemd-resolved by default.
> > 
> 
> Does this require systemd to be running? How does this affect DNS resolution 
> on a Fedora 33 container?

That's a good point. With systemd-resolved not running, resolution
might not work properly.

There's two parts to this:
- whether a fallback is included in the nss stack
- whether dns servers are appropriately configured

For the first part: there should be no issue.
Upstream recommends nss-resolve(8) the following:
> hosts:  ... resolve [!UNAVAIL=return] dns ...
Assuming that the same is done in Fedora, the nss stack will
automatically fall back to nss-dns when resolved is not running.

I guess the lesson here is the nsswitch.conf change should be
clarified in the proposal.

For the second part: the answer is complicated.
When /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf,
nss-dns does not work when systemd-resolved stops. In the case of a
container without systemd running, this will be a broken symlink, and
nss-dns will not work either.

But we seem to already have this problem to some extent.
NetworkManager allows /etc/resolv.conf to be a symlink to
/run/NetworkManager/resolv.conf too, to support name servers
configured at run time with a read-only root, and with systemd
not running, NM won't either, and this will be a dangling symlink.

I'm not sure what the best path option here is. The path of least
resistance would be to simply leave /etc/resolv.conf out of this change.
nss-resolve doesn't care, and the effect is only on things which
don't use the nss stack, or read /etc/resolv.conf for other purposes.

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

Re: The Chromium Dilemma

[Omair Majid]

Florian Weimer  writes:

> * Omair Majid:
>
>> Florian Weimer  writes:
>>
>>> * Jan Kratochvil:
>>>
 gold is also limited by 'ulimit -S -n', I had to raise it while building 
 LLDB
 (using -DLLVM_USE_LINKER=gold).
>>>
>>> gold should either do this upon start (like OpenJDK does),
>>
>> Do you have any pointers to source or docs that explain the OpenJDK
>> technique for this?
>
> Uhm, now I have to look.  I hope it really does that, I noticed it only
> because it was possible to open more than 1024 files, contrary to what I
> expected based on the system configuration.
>
> The responsible code is os::init_2(), in
> src/hotspot/os/linux/os_linux.cpp:
>
>   if (MaxFDLimit) {
> // set the number of file descriptors to max. print out error
> // if getrlimit/setrlimit fails but continue regardless.
> struct rlimit nbr_files;
> int status = getrlimit(RLIMIT_NOFILE, _files);
> if (status != 0) {
>   log_info(os)("os::init_2 getrlimit failed: %s", os::strerror(errno));
> } else {
>   nbr_files.rlim_cur = nbr_files.rlim_max;
>   status = setrlimit(RLIMIT_NOFILE, _files);
>   if (status != 0) {
> log_info(os)("os::init_2 setrlimit failed: %s", os::strerror(errno));
>   }
> }
>   }
>
> rlim_max is what is sometimes called the hard limit, rlim_cur the soft
> limit.  It is the difference between “ulimit -S -n” and “ulimit -H -n”.
> The quoted code fragment raises the soft limit up to the hard limit,
> which is as far as you can go without additional privileges.
>
> Does this answer your question?

Yes, it does. Thanks.

(I was secretly hoping there was a way to bump rlim_cur past
the current value of rlim_max...)

Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
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 1823946] New: perl-libwww-perl-6.44 is available

[bugzilla]

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

Bug ID: 1823946
   Summary: perl-libwww-perl-6.44 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-libwww-perl
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com,
john.j5l...@gmail.com, ka...@ucw.cz,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.44
Current version/release in rawhide: 6.43-3.fc33
URL: http://search.cpan.org/dist/libwww-perl/

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


-- 
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: Summary/Minutes from today's FESCo Meeting (2020-04-13)

[Matthew Miller]

On Tue, Apr 14, 2020 at 05:48:56PM +0200, Kevin Kofler wrote:
> So Fedora is now officially an alpha version of RHEL. :-(

Fedora is a community that makes an free and open source operating system
platform. We enable our community members and other software developers to
build solutions for their users.

Fedora isn't an alpha version of anything, but there absolutely *is* room
within Fedora for building the software which will feed into the next
version of RHEL. (Definitely not a RHEL alpha version, because that's a
specific, different thing.)

This expands and builds on what we're doing as a project. Your statement
seems to belittle it, and I think that's exactly backwards.

And, let me extend this: anyone else who wants to come to Fedora and work
with us to build *their* open source operating system is welcome to, and we
as a project will figure out how to make space for that.

-- 
Matthew Miller

Fedora Project Leader
Not the Pope
___
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 System-Wide Change proposal: systemd-resolved

[James Cassell]

On Tue, Apr 14, 2020, at 3:23 PM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/systemd-resolved
> 
> == Summary ==
> 
> Enable systemd-resolved by default. glibc will perform name resolution
> using nss-resolve rather than nss-dns.
> 
> == Owner ==
> * Name: [[User:catanzaro| Michael Catanzaro]]
> * Email: 
> 
> == Detailed Description ==
> 
> We will enable systemd-resolved by default.
> 

Does this require systemd to be running? How does this affect DNS resolution on 
a Fedora 33 container?

V/r 
James Cassell
___
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 System-Wide Change proposal: systemd-resolved

[Kevin Fenzi]

On Tue, Apr 14, 2020 at 02:40:08PM -0500, Michael Catanzaro wrote:
> On Tue, Apr 14, 2020 at 2:33 pm, Michael Cronenworth 
> wrote:
> > Why wait?
> > 
> > This is something I've been interested in and was interested in
> > implementing in Fedora.
> 
> Caution mainly, so that we only make one major change at a time instead of
> two. The goal is to do this without generating too many new bug reports for
> the systemd developers all at the same time. My thinking was that if this
> change goes smoothly in F33, then it should be possible to enable DNS over
> TLS by default in F34.

Can you expand on what that means? 

Does it mean: 

a) systemd-resolved will use DNS over TLS if it detects that
the nameservers it is querying can do so (ie, it would do a query to
port 853 of the nameservers dhcp or static config gave it)

b) systemd-resolved will use DNS over TLS and always use some 'well
known' public dns servers for queries, ignoring locally configured
servers. 

I'm very much in favor of a, but not in favor of b. :) 

> That said, there are not currently any known compatibility problems with the
> DNS over TLS support as far as I know, so I would *expect* it to go smoothly
> regardless.
> 
> Of course, once systemd-resolved is enabled, then enabling or disabling DNS
> over TLS will be a one-line config file change in
> /etc/systemd/resolved.conf. :)

Is that going to be to set it to 'opportunistic' or 'true' ? 

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

FedoraRespin-31-updates-20200408.0 compose check report

[Fedora compose checker]

Missing expected images:

Soas live x86_64

Failed openQA tests: 5/35 (x86_64)

ID: 571959  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/571959
ID: 571976  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/571976
ID: 571977  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/571977
ID: 576964  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/576964
ID: 576979  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/576979

Passed openQA tests: 2/35 (x86_64)

Skipped non-gating openQA tests: 28 of 35
-- 
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

Fedora-32-20200414.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/2 (arm)

ID: 576450  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/576450

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

ID: 576371  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/576371
ID: 576372  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/576372
ID: 576375  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/576375
ID: 576379  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/576379
ID: 576380  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/576380
ID: 576385  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/576385
ID: 576406  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/576406
ID: 576417  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/576417
ID: 576420  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/576420
ID: 576446  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/576446
ID: 576448  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/576448
ID: 576463  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/576463
ID: 576470  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/576470
ID: 576478  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/576478
ID: 576489  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/576489
ID: 576493  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/576493
ID: 576500  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/576500
ID: 576522  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/576522
ID: 576531  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/576531
ID: 576536  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/576536
ID: 576537  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/576537

Passed openQA tests: 150/171 (x86_64)

Skipped non-gating openQA tests: 1 of 173
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Adam Williamson]

On Tue, 2020-04-14 at 15:23 -0400, Ben Cotton wrote:
> 

> === Caching ===
> 
> systemd-resolved caches DNS queries for a short while. This can
> [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
> dramatically] improve performance for applications that do not already
> manually cache their own DNS results. (Generally, only web browsers
> bother with manually caching DNS results.)
> 
> === Split DNS ===

Doesn't NetworkManager already broadly address both of these on all
installations where it's used (which is all Fedora installs by
default)?
-- 
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

Fedora rawhide compose report: 20200414.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20200413.n.0
NEW: Fedora-Rawhide-20200414.n.0

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

Size of added packages:  4.25 MiB
Size of dropped packages:12.04 MiB
Size of upgraded packages:   1.91 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Games live x86_64
Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20200414.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: androwarn-1.6.1-3.fc33
Summary: Static code analyzer for malicious Android applications
RPMs:androwarn
Size:173.88 KiB

Package: golang-github-evilsocket-islazy-1.10.6-1.fc33
Summary: Go library containing a set of opinionated packages
RPMs:golang-github-evilsocket-islazy-devel
Size:39.40 KiB

Package: python-click-help-colors-0.8-1.fc33
Summary: Colorization of help messages in Click
RPMs:python3-click-help-colors
Size:112.29 KiB

Package: python-freeipa-1.0.2-1.fc33
Summary: Lightweight FreeIPA client
RPMs:python3-freeipa
Size:104.51 KiB

Package: simde-0.0.0-1.git29b9110.fc33
Summary: SIMD Everywhere
RPMs:simde-devel
Size:549.86 KiB

Package: surgescript-0.5.4.3-3.fc33
Summary: A scripting language for games
RPMs:surgescript surgescript-devel surgescript-static
Size:3.29 MiB


= DROPPED PACKAGES =
Package: disruptor-thrift-server-0.3.8-8.fc31
Summary: Thrift Server implementation backed by LMAX Disruptor
RPMs:disruptor-thrift-server disruptor-thrift-server-javadoc
Size:97.10 KiB

Package: glade3-2:3.8.6-8.fc32
Summary: User Interface Designer for GTK+ 2
RPMs:glade3 glade3-libgladeui glade3-libgladeui-devel
Size:11.26 MiB

Package: objectweb-asm3-3.3.1-23.fc32
Summary: Java bytecode manipulation and analysis framework
RPMs:objectweb-asm3 objectweb-asm3-javadoc
Size:586.46 KiB

Package: primitive-1.3-8.fc32
Summary: Utility methods for Java's primitive types
RPMs:primitive primitive-javadoc
Size:114.51 KiB


= UPGRADED PACKAGES =
Package:  Lmod-8.3.8-1.fc33
Old package:  Lmod-8.3.6-1.fc33
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.04 MiB
Size change:  2.13 KiB
Changelog:
  * Thu Apr 09 2020 Orion Poplawski  - 8.3.7-1
  - Update to 8.3.7

  * Tue Apr 14 2020 Orion Poplawski  - 8.3.8-1
  - Update to 8.3.8


Package:  MUMPS-5.3.1-1.fc33
Old package:  MUMPS-5.3.0-1.fc33
Summary:  A MUltifrontal Massively Parallel sparse direct Solver
RPMs: MUMPS MUMPS-common MUMPS-devel MUMPS-examples MUMPS-mpich 
MUMPS-mpich-devel MUMPS-mpich-examples MUMPS-openmp MUMPS-openmp-devel 
MUMPS-openmp-examples MUMPS-openmpi MUMPS-openmpi-devel MUMPS-openmpi-examples
Size: 75.65 MiB
Size change:  29.01 KiB
Changelog:
  * Mon Apr 13 2020 Antonio Trande  - 5.3.1-1
  - Release 5.3.1


Package:  appstream-data-32-6.fc33
Old package:  appstream-data-32-5.fc32
Summary:  Fedora AppStream metadata
RPMs: appstream-data
Size: 16.73 MiB
Size change:  541.28 KiB

Package:  bindfs-1.14.5-1.fc33
Old package:  bindfs-1.14.3-2.fc32
Summary:  Fuse filesystem to mirror a directory
RPMs: bindfs
Size: 249.80 KiB
Size change:  1.50 KiB
Changelog:
  * Mon Apr 13 2020 Filipe Rosset  - 1.14.5-1
  - Update to 1.14.5 fixes rhbz#1815902


Package:  blender-1:2.82a-3.fc33
Old package:  blender-1:2.82a-2.fc33
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-fonts blender-rpm-macros
Size: 171.89 MiB
Size change:  26.64 KiB
Changelog:
  * Sat Apr 11 2020 Luya Tshimbalanga  - 1:2.82a-3
  - Rebuild for oidn 1.2.0


Package:  bookworm-1.1.3-0.1.20200414git.c7c3643.fc33
Old package:  bookworm-1.1.2-3.fc33
Summary:  Simple, focused eBook reader
RPMs: bookworm
Size: 8.35 MiB
Size change:  649.20 KiB
Changelog:
  * Wed Apr 08 2020 Bob Hepple  - 1.1.2-4
  - resolve RHBZ#1822231

  * Tue Apr 14 2020 Bob Hepple  - 
1.1.3-0.1.20200414git.c7c3643
  - pre-release of 0.1.3


Package:  buildah-1.15.0-0.35.dev.gitc404c89.fc33
Old package:  buildah-1.15.0-0.33.dev.gitf7ff4c1.fc33
Summary:  A command line tool used for creating OCI Images
RPMs: buildah buildah-tests
Size: 87.66 MiB
Size change:  -87.96 KiB
Changelog:
  * Mon Apr 13 2020 RH Container Bot  - 
1.15.0-0.34.dev.git7a88d7e
  - autobuilt 7a88d7e

  * Mon Apr 13 2020 RH Container Bot  - 
1.15.0-0.35.dev.gitc404c89
  - autobuilt c404c89


Package:  cfdg-3.3-1.fc33
Old package:  cfdg-3.2-4.fc32
Summary:  Context Free Design Grammar
RPMs: cfdg
Size: 2.74 MiB
Size change:  57.45 KiB
Changelog:
  * Mon Apr 13 2020 Gwyn Ciesla  - 3.3-1
  - 3.3


Package:  clojure-1:1.9.0-0.beta3.1.fc33
Old package:  clojure-1:1.9.0-0.alpha15.1.fc33
Summary

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Michael Catanzaro]

On Tue, Apr 14, 2020 at 2:33 pm, Michael Cronenworth  
wrote:

Why wait?

This is something I've been interested in and was interested in 
implementing in Fedora.


Caution mainly, so that we only make one major change at a time instead 
of two. The goal is to do this without generating too many new bug 
reports for the systemd developers all at the same time. My thinking 
was that if this change goes smoothly in F33, then it should be 
possible to enable DNS over TLS by default in F34.


That said, there are not currently any known compatibility problems 
with the DNS over TLS support as far as I know, so I would *expect* it 
to go smoothly regardless.


Of course, once systemd-resolved is enabled, then enabling or disabling 
DNS over TLS will be a one-line config file change in 
/etc/systemd/resolved.conf. :)


___
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 System-Wide Change proposal: systemd-resolved

[Michael Cronenworth]

On 4/14/20 2:23 PM, Ben Cotton wrote:

=== DNS over TLS ===

systemd-resolved supports DNS over TLS (different from DNS over
HTTPS). Although this feature will not initially be enabled by
default, using systemd-resolved will enable us to turn on DNS over TLS
in a future Fedora release, providing improved security if the user's
DNS server supports DNS over TLS.


Why wait?

This is something I've been interested in and was interested in implementing in 
Fedora.
___
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: The Chromium Dilemma

[Florian Weimer]

* Omair Majid:

> Florian Weimer  writes:
>
>> * Jan Kratochvil:
>>
>>> gold is also limited by 'ulimit -S -n', I had to raise it while building 
>>> LLDB
>>> (using -DLLVM_USE_LINKER=gold).
>>
>> gold should either do this upon start (like OpenJDK does),
>
> Do you have any pointers to source or docs that explain the OpenJDK
> technique for this?

Uhm, now I have to look.  I hope it really does that, I noticed it only
because it was possible to open more than 1024 files, contrary to what I
expected based on the system configuration.

The responsible code is os::init_2(), in
src/hotspot/os/linux/os_linux.cpp:

  if (MaxFDLimit) {
// set the number of file descriptors to max. print out error
// if getrlimit/setrlimit fails but continue regardless.
struct rlimit nbr_files;
int status = getrlimit(RLIMIT_NOFILE, _files);
if (status != 0) {
  log_info(os)("os::init_2 getrlimit failed: %s", os::strerror(errno));
} else {
  nbr_files.rlim_cur = nbr_files.rlim_max;
  status = setrlimit(RLIMIT_NOFILE, _files);
  if (status != 0) {
log_info(os)("os::init_2 setrlimit failed: %s", os::strerror(errno));
  }
}
  }

rlim_max is what is sometimes called the hard limit, rlim_cur the soft
limit.  It is the difference between “ulimit -S -n” and “ulimit -H -n”.
The quoted code fragment raises the soft limit up to the hard limit,
which is as far as you can go without additional privileges.

Does this answer your question?

There is some risk in doing this, if the JVM uses JNI with some library
that still uses the select system call (with the risk of memory
corruption due to the use of FD_SET/FD_CLR with out-of-range
descriptors), but for the JVM, this is likely the right trade-off.

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

Fedora 33 System-Wide Change proposal: systemd-resolved

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/systemd-resolved

== Summary ==

Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.

== Owner ==
* Name: [[User:catanzaro| Michael Catanzaro]]
* Email: 

== Detailed Description ==

We will enable systemd-resolved by default.

# We will change the
[https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233e5e984a487e385def0ddca/f/90-default.preset
fedora-release presets] to enable systemd-resolved instead of disable
it.
# systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede5d234b7878753/f/systemd.spec#_606
a %post scriplet] to enable nss-myhostname and nss-systemd by either
(a) modifying authselect's user-nsswitch.conf template, if authselect
is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
will work with the systemd maintainers to enable nss-resolve here as
well.
# We will work with the authselect maintainers to update authselect's
minimal and nis profiles to enforce nss-resolve. These profiles modify
the hosts line of /etc/resolv.conf. (By default, Fedora uses
authselect's sssd profile, which does not modify the hosts line and
therefore does not have this problem.)
# We will remove our downstream patch to systemd that prevents systemd
from symlinking /etc/resolv.conf to
/run/systemd/resolve/stub-resolv.conf on new installs. For system
upgrades, a systemd-libs %post scriptlet will be used to reassign the
symlink during upgrade. Upon detecting this symlink, NetworkManager
will automatically enable its systemd-resolved support and configure
split DNS as appropriate.

systemd-resolved has been enabled by default in Ubuntu since Ubuntu
16.10, but please note we are doing this differently than Ubuntu has.
Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
nss-dns provided by glibc upstream, so glibc on Ubuntu continues to
read /etc/resolv.conf, as is traditional. This extra step is not
useful and not recommended by upstream. We want to follow upstream
recommendations in using nss-resolve instead.

If you do not wish to use systemd-resolved, then manual intervention
will be required to disable it:

* Modify /etc/authselect/user-nsswitch.conf and remove `resolve
[!UNAVAIL=return]` from the hosts line. Run `authselect
apply-changes`. (If you have disabled authselect, then edit
/etc/nsswitch.conf directly.)
* Disable and stop systemd-resolved.service.
* Restart the NetworkManager service. NetworkManager will then create
a traditional /etc/resolv.conf. (If you are not using NetworkManager,
you may create your own /etc/resolv.conf.)

== Benefit to Fedora ==

=== Standardization ===

Fedora will continue its history of enabling new systemd-provided
services whenever it makes sense to do so. Standardizing on upstream
systemd services is beneficial to the broader Linux ecosystem in
addition to Fedora, since standardizing reduces behavior differences
between different Linux distributions. Sadly, Fedora is no longer
leading in this area. Ubuntu has enabled systemd-resolved by default
since Ubuntu 16.10, so by the time Fedora 33 is released, we will be
three years behind Ubuntu here.

=== resolvectl ===

`resolvectl` has several useful functions (e.g. `resolvectl status` or
`resolvectl query`) that will be enabled out-of-the-box.

=== Caching ===

systemd-resolved caches DNS queries for a short while. This can
[https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
dramatically] improve performance for applications that do not already
manually cache their own DNS results. (Generally, only web browsers
bother with manually caching DNS results.)

=== Split DNS ===

When systemd-resolved is enabled, users who use multiple VPNs at the
same time will notice that DNS requests are now sent to the correct
DNS server by default. Previously, this scenario would result in
embarrassing "DNS leaks" and, depending on the order that the VPN
connections were established, possible failure to resolve private
resources. These scenarios will now work properly. For example,
consider the scenario of Distrustful Denise, who (quite reasonably)
does not trust her ISP. Denise uses a public VPN service,
public-vpn.example.com, to hide her internet activity from her ISP,
but she also needs to use her employer's corporate VPN,
corporation.example.com, in order to access internal company resources
while working from home. Using the Network panel in System Settings,
Denise has configured her employer's VPN to "use this connection only
for resources on its network." Distrustful Denise expects that her
employer's VPN will receive all traffic for corporation.example.com,
and no other traffic. And while this mostly works in Fedora 32, she
discovers that it does not work properly for DNS:

* If Denise connects to public-vpn.example.com first and
corporation.example.com second, she is unable to access internal
company resources. All DNS 

Fedora 33 System-Wide Change proposal: systemd-resolved

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/systemd-resolved

== Summary ==

Enable systemd-resolved by default. glibc will perform name resolution
using nss-resolve rather than nss-dns.

== Owner ==
* Name: [[User:catanzaro| Michael Catanzaro]]
* Email: 

== Detailed Description ==

We will enable systemd-resolved by default.

# We will change the
[https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233e5e984a487e385def0ddca/f/90-default.preset
fedora-release presets] to enable systemd-resolved instead of disable
it.
# systemd-libs currently has
[https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede5d234b7878753/f/systemd.spec#_606
a %post scriplet] to enable nss-myhostname and nss-systemd by either
(a) modifying authselect's user-nsswitch.conf template, if authselect
is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We
will work with the systemd maintainers to enable nss-resolve here as
well.
# We will work with the authselect maintainers to update authselect's
minimal and nis profiles to enforce nss-resolve. These profiles modify
the hosts line of /etc/resolv.conf. (By default, Fedora uses
authselect's sssd profile, which does not modify the hosts line and
therefore does not have this problem.)
# We will remove our downstream patch to systemd that prevents systemd
from symlinking /etc/resolv.conf to
/run/systemd/resolve/stub-resolv.conf on new installs. For system
upgrades, a systemd-libs %post scriptlet will be used to reassign the
symlink during upgrade. Upon detecting this symlink, NetworkManager
will automatically enable its systemd-resolved support and configure
split DNS as appropriate.

systemd-resolved has been enabled by default in Ubuntu since Ubuntu
16.10, but please note we are doing this differently than Ubuntu has.
Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional
nss-dns provided by glibc upstream, so glibc on Ubuntu continues to
read /etc/resolv.conf, as is traditional. This extra step is not
useful and not recommended by upstream. We want to follow upstream
recommendations in using nss-resolve instead.

If you do not wish to use systemd-resolved, then manual intervention
will be required to disable it:

* Modify /etc/authselect/user-nsswitch.conf and remove `resolve
[!UNAVAIL=return]` from the hosts line. Run `authselect
apply-changes`. (If you have disabled authselect, then edit
/etc/nsswitch.conf directly.)
* Disable and stop systemd-resolved.service.
* Restart the NetworkManager service. NetworkManager will then create
a traditional /etc/resolv.conf. (If you are not using NetworkManager,
you may create your own /etc/resolv.conf.)

== Benefit to Fedora ==

=== Standardization ===

Fedora will continue its history of enabling new systemd-provided
services whenever it makes sense to do so. Standardizing on upstream
systemd services is beneficial to the broader Linux ecosystem in
addition to Fedora, since standardizing reduces behavior differences
between different Linux distributions. Sadly, Fedora is no longer
leading in this area. Ubuntu has enabled systemd-resolved by default
since Ubuntu 16.10, so by the time Fedora 33 is released, we will be
three years behind Ubuntu here.

=== resolvectl ===

`resolvectl` has several useful functions (e.g. `resolvectl status` or
`resolvectl query`) that will be enabled out-of-the-box.

=== Caching ===

systemd-resolved caches DNS queries for a short while. This can
[https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846
dramatically] improve performance for applications that do not already
manually cache their own DNS results. (Generally, only web browsers
bother with manually caching DNS results.)

=== Split DNS ===

When systemd-resolved is enabled, users who use multiple VPNs at the
same time will notice that DNS requests are now sent to the correct
DNS server by default. Previously, this scenario would result in
embarrassing "DNS leaks" and, depending on the order that the VPN
connections were established, possible failure to resolve private
resources. These scenarios will now work properly. For example,
consider the scenario of Distrustful Denise, who (quite reasonably)
does not trust her ISP. Denise uses a public VPN service,
public-vpn.example.com, to hide her internet activity from her ISP,
but she also needs to use her employer's corporate VPN,
corporation.example.com, in order to access internal company resources
while working from home. Using the Network panel in System Settings,
Denise has configured her employer's VPN to "use this connection only
for resources on its network." Distrustful Denise expects that her
employer's VPN will receive all traffic for corporation.example.com,
and no other traffic. And while this mostly works in Fedora 32, she
discovers that it does not work properly for DNS:

* If Denise connects to public-vpn.example.com first and
corporation.example.com second, she is unable to access internal
company resources. All DNS 

Re: The Chromium Dilemma

[Omair Majid]

Hi,

Florian Weimer  writes:

> * Jan Kratochvil:
>
>> gold is also limited by 'ulimit -S -n', I had to raise it while building LLDB
>> (using -DLLVM_USE_LINKER=gold).
>
> gold should either do this upon start (like OpenJDK does),

Do you have any pointers to source or docs that explain the OpenJDK
technique for this?

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
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: Call for testers for rpmautospec in staging

[Vít Ondruch]

Dne 14. 04. 20 v 16:30 Miro Hrončok napsal(a):
> On 14. 04. 20 15:47, Pierre-Yves Chibon wrote:
>> On Tue, Apr 14, 2020 at 12:46:11PM +0200, Vít Ondruch wrote:
>>>
>>> Dne 09. 04. 20 v 15:43 Pierre-Yves Chibon napsal(a):

 PS:
   - F32 update:
 https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f41380eb9
   - F31 update:
 https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ee46bf2cd
   - F30 update:
 https://bodhi.fedoraproject.org/updates/FEDORA-2020-081a876918


>>>
>>> Could be the source package renamed s/python-rpmautospec/rpmautospec/.
>>> The `python-` prefix does not help with the discoverability at all.
>>
>> Considering that rpmautospec is mostly a python module with two koji
>> plugins and
>> a small CLI


In your initial email, you have mentioned rpmautospec and
rpmautospec-rpm-macros. I was interested in how things are done and non
of the packages available in Fedora correspond to the SRPM. This makes
the project undiscoverable (not mentioning the proposed rewrite in Rust
:wink:)


Vít


>> , it seemed appropriate to us to follow the python naming guidelines,
>> and this is how we understand them.
>
> Being the current de-facto maintainer of the Python Packaging
> guidelines, let me followup on that.
>
> The package produces several installable packages:
>
> - koji-builder-plugin-rpmautospec
> - koji-hub-plugin-rpmautospec
> - python3-rpmautospec
> - rpmautospec
> - rpmautospec-rpm-macros
>
> And all of them seem to follow the naming guidelines and conventions.
>
> As for the component/SRPM name, the guidelines are pretty loose here.
> Both "rpmautospec" and "python-rpmautospec" SRPM names are valid
> depending on how you perceive the package.
>
> The Python guidelines explicitly say:
>
> "This rule [using the python- prefix for SRPM] does not apply to
> applications."
>
> And obviously, the source package does contain both application and
> other things, hence it is really up to the maintainer.
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Vít Ondruch]

Dne 14. 04. 20 v 20:02 Vít Ondruch napsal(a):
> Dne 14. 04. 20 v 11:26 Miro Hrončok napsal(a):
>> On 14. 04. 20 11:18, Dan Horák wrote:
> patrikopravil: jruby pbrobinson: GConf2, jruby
 Why am I listed against jruby?
>>> you should search for your name in the full report
>>>
>>> jruby blocks rubygem-json and
>>>
>>> xapian-bindings (maintained by: denisarnaud, drago01,
>>> pbrobinson) xapian-bindings-1.4.14-3.fc33.src requires rubygem-json =
>>> 2.3.0-201.fc32
>> Note that it seem to me that several Ruby packages have jruby shebangs
>> in doc subpackages, mostly generating noise here. However I'm not sure
>> about this assumption, the real reason why rubygem-json-doc and
>> rubygem-json_pure-doc require /usr/bin/jruby is unknown to me. CCing Vít.
>>
> So there is json-java.gemspec file with shebang. We won't loose anything
> if this file is dropped or the shebang is removed. I don't think that
> anybody expects .gemspec files to be executable.
>
>
> I'll do something about it.


This should be fixed by:


rubygem-json-2.3.0-202.fc33

rubygem-json_pure-1.8.1-12.fc33



Vít

>
>
> Vít
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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-04-13)

[Jared K. Smith]

On Tue, Apr 14, 2020 at 11:58 AM Kevin Kofler 
wrote:

> So Fedora is now officially an alpha version of RHEL. :-(
>

Kevin, your comments like this are not helpful, and not in keeping with our
mantra of being excellent to each other.

As you're well aware, there's a cooperative relationship between Fedora and
RHEL.  Fedora serves as the upstream for RHEL, but that doesn't translate
into it being the alpha version of RHEL.  This ELN effort, from what I've
read about it (I haven't been a Red Hat insider for a long time, so I don't
have any non-public details about it) is aimed at making it easier for RHEL
to take advantage of the work done in Fedora, and even be more open about
the development.  I don't see how either of those are bad things, as long
as they don't pose a burden on Fedora developers.  From the discussions on
this mailing list, it looks like the team running the initiative has taken
great pains to clarify that they don't want to put any undue burden on
Fedora developers.

So, whether your agree with the decision that FESCo made or not, please
don't leave sniping comments like this -- they're not constructive.

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

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Vít Ondruch]

Dne 14. 04. 20 v 11:26 Miro Hrončok napsal(a):
> On 14. 04. 20 11:18, Dan Horák wrote:
 patrikopravil: jruby pbrobinson: GConf2, jruby
>>> Why am I listed against jruby?
>> you should search for your name in the full report
>>
>> jruby blocks rubygem-json and
>>
>> xapian-bindings (maintained by: denisarnaud, drago01,
>> pbrobinson) xapian-bindings-1.4.14-3.fc33.src requires rubygem-json =
>> 2.3.0-201.fc32
>
> Note that it seem to me that several Ruby packages have jruby shebangs
> in doc subpackages, mostly generating noise here. However I'm not sure
> about this assumption, the real reason why rubygem-json-doc and
> rubygem-json_pure-doc require /usr/bin/jruby is unknown to me. CCing Vít.
>

So there is json-java.gemspec file with shebang. We won't loose anything
if this file is dropped or the shebang is removed. I don't think that
anybody expects .gemspec files to be executable.


I'll do something about it.


Vít

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

Re: The Chromium Dilemma

[Robbie Harwood]

Tom Callaway  writes:

> Recently, someone filed a bug against chromium, noting that it was
> benchmarking notably slower than Google Chrome or chromium-freeworld
> (from rpmfusion). I tested locally and confirmed it. They suspected
> that Fedora's optflags were to blame, but since chromium doesn't use
> them anymore, that wasn't it. chromium-freeworld enables some media
> codecs we cannot, but this shouldn't affect javascript benchmark
> tests. VAAPI is turned on in both builds, but not in Google Chrome.
>
> Ultimately, the culprit was in how chromium is built for Fedora. There
> are two ways to build chromium: as a giant static binary (which is how
> Google Chrome and chromium-freeworld are built) and as a collection of
> shared libraries (which is how Fedora's chromium is built). I did a
> test build of a static version of Fedora's chromium and the benchmark
> performance went up to expected levels. It's worth noting that IMHO,
> the performance loss is noticeable, but the browser is still usable.
>
> So, you might be asking, why does Fedora build in shared mode? There are
> two main reasons:
>
> 1) To enable users to be able to swap out the media components from
> Fedora with a "freeworld" version.
>
> 2) To keep the size down on the chrome-remote-desktop subpackage
> (since it can share the "internal libs" from chromium).
>
> Switching to static mode gives us:
>
> 1) Fully working krb5 (because it would resolve the symbol clash
> caused by the use of chromium's boringssl fork). This bug has been
> outstanding for a few years now.

Biased of course, but this fix is really attractive to me.  (For those
who haven't experienced the issue, Kerberized browser login using
FEDORAPROJECT.ORG is more likely to crash chromium than log in.)

It sounds like from downthread that rpmfusion/freeworld isn't a concern
anymore.  That I think leaves chrome-remote-desktop, which doesn't seem
a huge concern (but correct me if that's not right).

So much as it pains me to suggest static linking, that would be my
preference.

Thanks,
--Robbie


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

Fedora-IoT-32-20200414.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 1/8 (x86_64)

Old failures (same test failed in Fedora-IoT-32-20200413.0):

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

Passed openQA tests: 7/8 (x86_64)

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

[EPEL-devel] Re: Python macro backports for EPEL reviews needed

[Miro Hrončok]

On 14. 04. 20 18:46, Troy Dawson wrote:

Yep, I'm having a hard time finding anything relevant to test.
I have verified it doesn't conflict with any other rpm macro, but I'm
pretty sure you had already checked that.
So, I'm giving it a thumbs up.
And I'll give it a thumbs up on the pull requests as well.



EPEL 7 update and buildroot override:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3c0bec7842
https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-7-24


EPEL 8 update and buildroot override:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d2bb92fb39
https://bodhi.fedoraproject.org/overrides/epel-rpm-macros-8-10


I've disabled both time based and karma based push. We can observe the EPEL 
builds and decide whether to push this or not in ~1 month.



In case something is needed for EPEL 8 Playground, please do so, I have no idea 
really, sorry about that.



Thanks, Troy.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Bug 1823182] perl-CPANPLUS-0.9908 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[EPEL-devel] Re: Python macro backports for EPEL reviews needed

[Troy Dawson]

On Tue, Apr 14, 2020 at 9:27 AM Miro Hrončok  wrote:
>
> On 14. 04. 20 17:40, Troy Dawson wrote:
> > On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok  wrote:
> >>
> >> On 14. 04. 20 15:56, Troy Dawson wrote:
> >>> Hi Miro,
> >>> I've taken a look, but haven't done any testing.
> >>
> >> Thanks.
> >>
> >>> EPEL6 patch - no.  Even if it works, I'd say no.  We're at the last 7
> >>> months before EOL and I don't want the EPEL6 stuff to have changes
> >>> like this.  I could be outvoted by this, but I believe most of the
> >>> other EPEL packagers would feel this way.
> >>
> >> Makes perfect sense.
> >>
> >>> EPEL7 patch - This would require some testing.  When we tried to turn
> >>> on the python automatic-dependency checking, there were things that
> >>> broke on EPEL7 so they never got implemented.  What, or how they
> >>> broke, I don't currently know.  I just know that they did, and there
> >>> wasn't a big enough demand to debug.  As in zero demand.  Nobody asked
> >>> for it in EPEL7, only EPEL8.  So I'm not even sure this would be worth
> >>> the testing.  Has anyone asked for this?
> >>
> >> Not yet. But If we want packagers to start using %pycached, I know there 
> >> are
> >> some of them who would blindly merge their master branch to epel7 and they
> >> expect it will work. I suggest that we backport %pycached only, the name is
> >> unlikely to clash with anything. %python can be separated and not 
> >> backported.
> >> Sounds good?
> >>
> >
> > Yep, sounds good to me.
>
> Amended https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14
>
> >>> EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora,
> >>> so I'm in favor of this.
> >>> I'm pretty sure the %pycached shouldn't be a problem.
> >>
> >> I agree.
> >>
> >>> What is %python supposed to resolve to?  To me it looks like
> >>> /usr/bin/python ... which there isn't any in RHEL8.  And, I thought
> >>> Fedora got rid of it also, in favor of specifically doing python2 or
> >>> python3.  Or did that change?
> >>
> >> So the main idea was that based on some FPC and RPMdevs discussions about
> >> underscor-prefixed macros, packagers should not be using those directly, 
> >> however
> >> our guidelines were full of referecens to %{__python3}. We have come up 
> >> with a
> >> conclusion:
> >>
> >> Macros with underscores, such as %__python3 are intended to be reset to 
> >> change
> >> bahvior of other macros (e.g. when you set %__python to 
> >> /usr/bin/pythhon3.4 on
> >> EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to 
> >> be
> >> used in specs (e.g. you do `%{python3} -m pytest` rather than 
> >> `%{__python3} -m
> >> pytest`.
> >>
> >> Details:
> >> https://pagure.io/packaging-committee/issue/907
> >> https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comment-30941
> >>
> >> The only problem was the %{python} macro. When you redefine %__python to a 
> >> sane
> >> (explicit) value, you want %{python} to work, because e.g. 
> >> %{python_version}
> >> works. But we didn't want to encourage usage of "unversioned python" by 
> >> adding
> >> %{python}.
> >>
> >> So Fedora now has a %{python} macro: If %__python is /usr/bin/python 
> >> (backwards
> >> compatible default), %{python} gives you an error. If %__python is anything
> >> else, %{python} gives that to you.
> >>
> >
> > Ahh ... now that you explain it, I was reading it totally backwards.
> > I'd still like to test it on a variety of packages, but unless others
> > have some type of objection, as long as it passes the tests, I'm good
> > with it.
>
> What kind of packages would need the test? This is mostly backwards 
> compatible.
> The only packages that could be problematic are packages that use a constructs
> like this:
>
> %{!?python:...} or %if %{defined python}
>
> -> previously %python was not defined, now it is and hence the conditional 
> will
> have a different result
>
> Or like this:
>
> %global pyver_sitelib %python%{pyver}_sitelib
>
> -> previously %python was not defined, now it is and hence the code produces
> invalid result
>
> I suppose such cases could be figured out with a grep. Is there something like
> https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz but for epel 
> branches?
>

Yep, I'm having a hard time finding anything relevant to test.
I have verified it doesn't conflict with any other rpm macro, but I'm
pretty sure you had already checked that.
So, I'm giving it a thumbs up.
And I'll give it a thumbs up on the pull requests as well.
Troy
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Fedora 32 compose report: 20200414.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200413.n.0
NEW: Fedora-32-20200414.n.0

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  earlyoom-1.6-1.fc32
Old package:  earlyoom-1.5-1.fc32
Summary:  Early OOM Daemon for Linux
RPMs: earlyoom
Size: 168.85 KiB
Size change:  1.25 KiB
Changelog:
  * Fri Apr 10 2020 Neal Gompa  - 1.5-2
  - Add Supplements to fedora-release-workstation for F32+ to work around 
RHBZ#1814306

  * Sat Apr 11 2020 Vitaly Zaitsev  - 1.6-1
  - Updated to version 1.6.


Package:  fedora-release-32-1
Old package:  fedora-release-32-0.8
Summary:  Fedora release files
RPMs: fedora-release fedora-release-cinnamon fedora-release-cloud 
fedora-release-common fedora-release-container fedora-release-coreos 
fedora-release-iot fedora-release-kde fedora-release-matecompiz 
fedora-release-server fedora-release-silverblue fedora-release-snappy 
fedora-release-soas fedora-release-workstation fedora-release-xfce
Size: 201.76 KiB
Size change:  2.64 KiB
Changelog:
  * Mon Mar 23 2020 Stephen Gallagher  - 32-0.9
  - Enable log rotation (BZ#1655153)

  * Wed Apr 01 2020 Christian Glombek  32-0.10
  - Add IoT user preset to disable grub-boot-success.timer

  * Thu Apr 09 2020 Mohan Boddu  - 32-1
  - Setup for F32 Final


Package:  fedora-repos-32-1
Old package:  fedora-repos-32-0.7
Summary:  Fedora package repositories
RPMs: fedora-gpg-keys fedora-repos fedora-repos-ostree 
fedora-repos-rawhide
Size: 131.35 KiB
Size change:  1.75 KiB
Changelog:
  * Thu Apr 09 2020 Kalev Lember  - 32-0.8
  - Switch to metalink for fedora-cisco-openh264 and disable repo gpgcheck
(#1768206)
  - Use the same metadata_expire time for fedora-cisco-openh264 and -debuginfo
  - Remove enabled_metadata key for fedora-cisco-openh264

  * Thu Apr 09 2020 Mohan Boddu  - 32-1
  - Setup for F32 Final
  - Disable testing repos


Package:  gnome-shell-3.36.1-4.fc32
Old package:  gnome-shell-3.36.1-3.fc32
Summary:  Window management and application launching for GNOME
RPMs: gnome-shell
Size: 7.61 MiB
Size change:  -915 B
Changelog:
  * Mon Apr 13 2020 Florian M??llner  - 3.36.1-4
  - Fix translated folder names
Resolves: #1822336


Package:  gnome-weather-3.36.1-1.fc32
Old package:  gnome-weather-3.36.0-1.fc32
Summary:  A weather application for GNOME
RPMs: gnome-weather
Size: 4.96 MiB
Size change:  158 B
Changelog:
  * Fri Apr 10 2020 Kalev Lember  - 3.36.1-1
  - Update to 3.36.1


Package:  gtk3-3.24.18-1.fc32
Old package:  gtk3-3.24.16-2.fc32
Summary:  GTK+ graphical user interface library
RPMs: gtk-update-icon-cache gtk3 gtk3-devel gtk3-devel-docs 
gtk3-immodule-xim gtk3-immodules gtk3-tests
Size: 76.78 MiB
Size change:  1.66 MiB
Changelog:
  * Fri Apr 03 2020 Kalev Lember  - 3.24.17-1
  - Update to 3.24.17

  * Fri Apr 10 2020 Kalev Lember  - 3.24.18-1
  - Update to 3.24.18


Package:  xorg-x11-drv-intel-2.99.917-45.20200205.fc32
Old package:  xorg-x11-drv-intel-2.99.917-44.20200205.fc32
Summary:  Xorg X11 Intel video driver
RPMs: xorg-x11-drv-intel
Size: 1.44 MiB
Size change:  -1.79 KiB
Changelog:
  * Fri Apr 10 2020 Olivier Fourdan  - 2.99.917-45
  - Rebuild with newer gcc (bug #1808767)


Package:  zezere-0.4-2.fc32
Old package:  zezere-0.3-2.fc32
Summary:  A provisioning service for Fedora IoT
RPMs: zezere zezere-ignition
Size: 61.42 KiB
Size change:  2.64 KiB
Changelog:
  * Tue Apr 07 2020 Peter Robinson  0.4-1
  - Update to 0.4

  * Wed Apr 08 2020 Peter Robinson  - 0.4-2
  - Fix ignition keys fragment merging (rhbz 1820614)



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

[EPEL-devel] Re: Python macro backports for EPEL reviews needed

[Miro Hrončok]

On 14. 04. 20 17:40, Troy Dawson wrote:

On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok  wrote:


On 14. 04. 20 15:56, Troy Dawson wrote:

Hi Miro,
I've taken a look, but haven't done any testing.


Thanks.


EPEL6 patch - no.  Even if it works, I'd say no.  We're at the last 7
months before EOL and I don't want the EPEL6 stuff to have changes
like this.  I could be outvoted by this, but I believe most of the
other EPEL packagers would feel this way.


Makes perfect sense.


EPEL7 patch - This would require some testing.  When we tried to turn
on the python automatic-dependency checking, there were things that
broke on EPEL7 so they never got implemented.  What, or how they
broke, I don't currently know.  I just know that they did, and there
wasn't a big enough demand to debug.  As in zero demand.  Nobody asked
for it in EPEL7, only EPEL8.  So I'm not even sure this would be worth
the testing.  Has anyone asked for this?


Not yet. But If we want packagers to start using %pycached, I know there are
some of them who would blindly merge their master branch to epel7 and they
expect it will work. I suggest that we backport %pycached only, the name is
unlikely to clash with anything. %python can be separated and not backported.
Sounds good?



Yep, sounds good to me.


Amended https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14


EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora,
so I'm in favor of this.
I'm pretty sure the %pycached shouldn't be a problem.


I agree.


What is %python supposed to resolve to?  To me it looks like
/usr/bin/python ... which there isn't any in RHEL8.  And, I thought
Fedora got rid of it also, in favor of specifically doing python2 or
python3.  Or did that change?


So the main idea was that based on some FPC and RPMdevs discussions about
underscor-prefixed macros, packagers should not be using those directly, however
our guidelines were full of referecens to %{__python3}. We have come up with a
conclusion:

Macros with underscores, such as %__python3 are intended to be reset to change
bahvior of other macros (e.g. when you set %__python to /usr/bin/pythhon3.4 on
EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to be
used in specs (e.g. you do `%{python3} -m pytest` rather than `%{__python3} -m
pytest`.

Details:
https://pagure.io/packaging-committee/issue/907
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comment-30941

The only problem was the %{python} macro. When you redefine %__python to a sane
(explicit) value, you want %{python} to work, because e.g. %{python_version}
works. But we didn't want to encourage usage of "unversioned python" by adding
%{python}.

So Fedora now has a %{python} macro: If %__python is /usr/bin/python (backwards
compatible default), %{python} gives you an error. If %__python is anything
else, %{python} gives that to you.



Ahh ... now that you explain it, I was reading it totally backwards.
I'd still like to test it on a variety of packages, but unless others
have some type of objection, as long as it passes the tests, I'm good
with it.


What kind of packages would need the test? This is mostly backwards compatible. 
The only packages that could be problematic are packages that use a constructs 
like this:


%{!?python:...} or %if %{defined python}

-> previously %python was not defined, now it is and hence the conditional will 
have a different result


Or like this:

%global pyver_sitelib %python%{pyver}_sitelib

-> previously %python was not defined, now it is and hence the code produces 
invalid result


I suppose such cases could be figured out with a grep. Is there something like 
https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz but for epel branches?


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: RANT: Flatpaks suck to implement (well poorly documented in a holistic way really)

[Adam Williamson]

On Mon, 2020-04-13 at 17:52 -0500, Richard Shaw wrote:
> 
> 2. JSON may be fine for machine readability but it SUCKS for human
> readability. Both brackets and braces! Do I need a "," after that one? All
> I know is I screw around with it until vim doesn't show me any more red
> highlights.

Please endorse my RFC:

https://www.happyassassin.net/2017/09/07/a-modest-proposal/
-- 
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: The Chromium Dilemma

[Kevin Kofler]

Tom Callaway wrote:
> I would also be interested in seeing the patches where you set a specific
> component to be shared while the others were static.

See what I did to v8/BUILD.gn and v8/gni/v8.gni:
https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/f27/f/qtwebengine-everywhere-src-5.10.1-no-sse2.patch#_2647
(and the "shared_library("v8")" section that I added is mostly just copied 
from the "v8_component("v8")" section with "v8_component" changed to 
"shared_library"), though I am not sure how easily that works for more core 
components. (V8 is a bit of a special case.)

Also note that this is a quite old Chromium. The patch was abandoned with 
QtWebEngine 5.11. I already had to forward-port the V8 x87 backend to 5.10 
(it was removed from Chromium), which is why the patch had become so huge. 
Getting it to work with later versions was too much effort, and Fedora has 
dropped non-SSE2 x86 support systemwide around that time anyway. So I do not 
have a version of this patch for the current Chromium.

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

Re: The Chromium Dilemma

[Peter Robinson]

> Peter Robinson wrote:
> > People that want the Fedora version of the build, even without the
> > extra bits, would get rpmfusion if they happen to have rpmfusion
> > enabled for another reason.
>
> That's exactly why RPM Fusion does NOT Obsolete Fedora packages, but uses
> Conflicts or parallel installability instead.

If you read the email I was replying to that's what they were
proposing and hence why I made the comment.
___
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: The Chromium Dilemma

[Kevin Kofler]

Peter Robinson wrote:
> People that want the Fedora version of the build, even without the
> extra bits, would get rpmfusion if they happen to have rpmfusion
> enabled for another reason.

That's exactly why RPM Fusion does NOT Obsolete Fedora packages, but uses 
Conflicts or parallel installability instead.

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

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

[Kevin Kofler]

Stephen Gallagher wrote:
> * #2365 F33 System-Wide Change: ELN Buildroot and Compose  (sgallagh,
>   15:04:57)
>   * this received +7 in the ticket, so it is accepted  (sgallagh,
> 15:05:18)
>   * AGREED: ELN Buildroot and Compose is accepted (+7, 1, -0)
> (sgallagh, 15:05:36)

So Fedora is now officially an alpha version of RHEL. :-(

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

[EPEL-devel] Re: Python macro backports for EPEL reviews needed

[Troy Dawson]

On Tue, Apr 14, 2020 at 8:30 AM Miro Hrončok  wrote:
>
> On 14. 04. 20 15:56, Troy Dawson wrote:
> > Hi Miro,
> > I've taken a look, but haven't done any testing.
>
> Thanks.
>
> > EPEL6 patch - no.  Even if it works, I'd say no.  We're at the last 7
> > months before EOL and I don't want the EPEL6 stuff to have changes
> > like this.  I could be outvoted by this, but I believe most of the
> > other EPEL packagers would feel this way.
>
> Makes perfect sense.
>
> > EPEL7 patch - This would require some testing.  When we tried to turn
> > on the python automatic-dependency checking, there were things that
> > broke on EPEL7 so they never got implemented.  What, or how they
> > broke, I don't currently know.  I just know that they did, and there
> > wasn't a big enough demand to debug.  As in zero demand.  Nobody asked
> > for it in EPEL7, only EPEL8.  So I'm not even sure this would be worth
> > the testing.  Has anyone asked for this?
>
> Not yet. But If we want packagers to start using %pycached, I know there are
> some of them who would blindly merge their master branch to epel7 and they
> expect it will work. I suggest that we backport %pycached only, the name is
> unlikely to clash with anything. %python can be separated and not backported.
> Sounds good?
>

Yep, sounds good to me.

> > EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora,
> > so I'm in favor of this.
> > I'm pretty sure the %pycached shouldn't be a problem.
>
> I agree.
>
> > What is %python supposed to resolve to?  To me it looks like
> > /usr/bin/python ... which there isn't any in RHEL8.  And, I thought
> > Fedora got rid of it also, in favor of specifically doing python2 or
> > python3.  Or did that change?
>
> So the main idea was that based on some FPC and RPMdevs discussions about
> underscor-prefixed macros, packagers should not be using those directly, 
> however
> our guidelines were full of referecens to %{__python3}. We have come up with a
> conclusion:
>
> Macros with underscores, such as %__python3 are intended to be reset to change
> bahvior of other macros (e.g. when you set %__python to /usr/bin/pythhon3.4 on
> EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to be
> used in specs (e.g. you do `%{python3} -m pytest` rather than `%{__python3} -m
> pytest`.
>
> Details:
> https://pagure.io/packaging-committee/issue/907
> https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comment-30941
>
> The only problem was the %{python} macro. When you redefine %__python to a 
> sane
> (explicit) value, you want %{python} to work, because e.g. %{python_version}
> works. But we didn't want to encourage usage of "unversioned python" by adding
> %{python}.
>
> So Fedora now has a %{python} macro: If %__python is /usr/bin/python 
> (backwards
> compatible default), %{python} gives you an error. If %__python is anything
> else, %{python} gives that to you.
>
> Fedora 32:
>
> $ rpm --define '__python /usr/bin/python3.6' --eval '%python_version'
> 3.6
>
> $ rpm --define '__python /usr/bin/python3.6' --eval '%python'
> /usr/bin/python3.6
>
> $ rpm --eval '%python_version'
> 3.8
>
> $ rpm --eval '%python'
> error: Cannot use %python if %__python wasn't redefined to something other 
> than
> /usr/bin/python.
>
>
> EPEL 8:
>
> $ rpm --define '__python /usr/bin/python3.6' --eval '%python_version'
> 3.6
>
> $ rpm --define '__python /usr/bin/python3.6' --eval '%python'
> %python
>
> $ rpm --eval '%python_version'
> error: attempt to use unversioned python, define %__python to /usr/bin/python2
> or /usr/bin/python3 explicitly
>
> $ rpm --eval '%python'
> %python
>
>

Ahh ... now that you explain it, I was reading it totally backwards.
I'd still like to test it on a variety of packages, but unless others
have some type of objection, as long as it passes the tests, I'm good
with it.

> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[Test-Announce] Fedora 32 Candidate RC-1.2 Available Now!

[rawhide]

According to the schedule [1], Fedora 32 Candidate RC-1.2 is now
available for testing. Please help us complete all the validation
testing! For more information on release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.2_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.2_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.2_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.2_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.2_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.2_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_RC_1.2_Security_Lab

All RC priority test cases for each of these test pages [2] must
pass in order to meet the RC Release Criteria [3].

Help is available on #fedora-qa on irc.freenode.net [4], or on the
test list [5].

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-32/f-32-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Release_validation_test_plan
[3] https://fedoraproject.org/wiki/Fedora_32_RC_Release_Criteria
[4] irc://irc.freenode.net/fedora-qa
[5] https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/
___
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

[EPEL-devel] Re: Python macro backports for EPEL reviews needed

[Miro Hrončok]

On 14. 04. 20 15:56, Troy Dawson wrote:

Hi Miro,
I've taken a look, but haven't done any testing.


Thanks.


EPEL6 patch - no.  Even if it works, I'd say no.  We're at the last 7
months before EOL and I don't want the EPEL6 stuff to have changes
like this.  I could be outvoted by this, but I believe most of the
other EPEL packagers would feel this way.


Makes perfect sense.


EPEL7 patch - This would require some testing.  When we tried to turn
on the python automatic-dependency checking, there were things that
broke on EPEL7 so they never got implemented.  What, or how they
broke, I don't currently know.  I just know that they did, and there
wasn't a big enough demand to debug.  As in zero demand.  Nobody asked
for it in EPEL7, only EPEL8.  So I'm not even sure this would be worth
the testing.  Has anyone asked for this?


Not yet. But If we want packagers to start using %pycached, I know there are 
some of them who would blindly merge their master branch to epel7 and they 
expect it will work. I suggest that we backport %pycached only, the name is 
unlikely to clash with anything. %python can be separated and not backported. 
Sounds good?



EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora,
so I'm in favor of this.
I'm pretty sure the %pycached shouldn't be a problem.


I agree.


What is %python supposed to resolve to?  To me it looks like
/usr/bin/python ... which there isn't any in RHEL8.  And, I thought
Fedora got rid of it also, in favor of specifically doing python2 or
python3.  Or did that change?


So the main idea was that based on some FPC and RPMdevs discussions about 
underscor-prefixed macros, packagers should not be using those directly, however 
our guidelines were full of referecens to %{__python3}. We have come up with a 
conclusion:


Macros with underscores, such as %__python3 are intended to be reset to change 
bahvior of other macros (e.g. when you set %__python to /usr/bin/pythhon3.4 on 
EPEL 7, %{python3_version{ will be 3.4), macros without underscores are to be 
used in specs (e.g. you do `%{python3} -m pytest` rather than `%{__python3} -m 
pytest`.


Details:
https://pagure.io/packaging-committee/issue/907
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/27#comment-30941

The only problem was the %{python} macro. When you redefine %__python to a sane 
(explicit) value, you want %{python} to work, because e.g. %{python_version} 
works. But we didn't want to encourage usage of "unversioned python" by adding 
%{python}.


So Fedora now has a %{python} macro: If %__python is /usr/bin/python (backwards 
compatible default), %{python} gives you an error. If %__python is anything 
else, %{python} gives that to you.


Fedora 32:

$ rpm --define '__python /usr/bin/python3.6' --eval '%python_version'
3.6

$ rpm --define '__python /usr/bin/python3.6' --eval '%python'
/usr/bin/python3.6

$ rpm --eval '%python_version'
3.8

$ rpm --eval '%python'
error: Cannot use %python if %__python wasn't redefined to something other than 
/usr/bin/python.



EPEL 8:

$ rpm --define '__python /usr/bin/python3.6' --eval '%python_version'
3.6

$ rpm --define '__python /usr/bin/python3.6' --eval '%python'
%python

$ rpm --eval '%python_version'
error: attempt to use unversioned python, define %__python to /usr/bin/python2 
or /usr/bin/python3 explicitly


$ rpm --eval '%python'
%python


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Sven Lankes]

On Tue, Apr 14, 2020 at 11:06:27AM +0200, Miro Hrončok wrote:

> libacpi   orphan   1 weeks ago

I have re-claimed this and retired it (and yacpi which depends on it) properly.

While I was able to fix the FTBFS, I noticed that libacpi no longer
works sufficiently with modern kernels. 

Last $upstream release for the tools was 2007/2008 ...
...

-- 
sven === jabber/xmpp: s...@lankes.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: Unretire gjots2 (gtk heirarchical note jotter)

[Petr Pisar]

On Tue, Apr 14, 2020 at 04:51:04PM +0200, Alexander Ploumistos wrote:
> On Tue, Apr 14, 2020 at 4:40 PM Petr Pisar  wrote:
> >
> > On Tue, Apr 14, 2020 at 04:27:06PM +0200, Alexander Ploumistos wrote:
> > > The FSF address should be the most straightforward to fix.
> > >
> > Straightforward, but impossible for a pacakger. Because it's a part of the
> > license declaration, only an author can change it, as the license reads:
> >
> > [...]keep intact all the
> > notices that refer to this License [...]
> >
> > That's the reason why I consider this rpmlint warning quite unhelpful.
> >
> 
> Do you mean the author of the software or the license?

Author of the software. Author can replace the license declaration as well the
license text.

> I've seen that debated over and over again and my understanding is that
> packagers are not supposed to patch the file, but upstream developers (which
> is the case here) should correct that error.

Exactly.

> Our wiki links to a version of
> GPL 2 with the correct address:
> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address

That's a new revision of GPL 2. Author of the license, updates it whenever he
moves to a different place. That's fine. Author of the software just copies
the updated revision into his software. That's also fine.

-- Petr



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

Re: Unretire gjots2 (gtk heirarchical note jotter)

[Alexander Ploumistos]

On Tue, Apr 14, 2020 at 4:59 PM Paul Howarth  wrote:
>
> I view the rpmlint warning as a hint to try to get upstream to fix the
> license text. In the case of unresponsive upstreams, we just have to
> live with it.

I think we're all on the same page here, I made the suggestion bearing
in mind that Bob is the actual developer of the software.
___
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: Unretire gjots2 (gtk heirarchical note jotter)

[Paul Howarth]

On Tue, 14 Apr 2020 16:51:04 +0200
Alexander Ploumistos  wrote:

> On Tue, Apr 14, 2020 at 4:40 PM Petr Pisar  wrote:
> >
> > On Tue, Apr 14, 2020 at 04:27:06PM +0200, Alexander Ploumistos
> > wrote:  
> > > The FSF address should be the most straightforward to fix.
> > >  
> > Straightforward, but impossible for a pacakger. Because it's a part
> > of the license declaration, only an author can change it, as the
> > license reads:
> >
> > [...]keep intact all the
> > notices that refer to this License [...]
> >
> > That's the reason why I consider this rpmlint warning quite
> > unhelpful. 
> 
> Do you mean the author of the software or the license? I've seen that
> debated over and over again and my understanding is that packagers are
> not supposed to patch the file, but upstream developers (which is the
> case here) should correct that error. Our wiki links to a version of
> GPL 2 with the correct address:
> https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address

I view the rpmlint warning as a hint to try to get upstream to fix the
license text. In the case of unresponsive upstreams, we just have to
live with it.

Paul.
___
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: Unretire gjots2 (gtk heirarchical note jotter)

[Alexander Ploumistos]

On Tue, Apr 14, 2020 at 4:40 PM Petr Pisar  wrote:
>
> On Tue, Apr 14, 2020 at 04:27:06PM +0200, Alexander Ploumistos wrote:
> > The FSF address should be the most straightforward to fix.
> >
> Straightforward, but impossible for a pacakger. Because it's a part of the
> license declaration, only an author can change it, as the license reads:
>
> [...]keep intact all the
> notices that refer to this License [...]
>
> That's the reason why I consider this rpmlint warning quite unhelpful.
>

Do you mean the author of the software or the license? I've seen that
debated over and over again and my understanding is that packagers are
not supposed to patch the file, but upstream developers (which is the
case here) should correct that error. Our wiki links to a version of
GPL 2 with the correct address:
https://fedoraproject.org/wiki/Common_Rpmlint_issues#incorrect-fsf-address
___
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: Unretire gjots2 (gtk heirarchical note jotter)

[Petr Pisar]

On Tue, Apr 14, 2020 at 04:27:06PM +0200, Alexander Ploumistos wrote:
> The FSF address should be the most straightforward to fix.
> 
Straightforward, but impossible for a pacakger. Because it's a part of the
license declaration, only an author can change it, as the license reads:

[...]keep intact all the
notices that refer to this License [...]

That's the reason why I consider this rpmlint warning quite unhelpful.

-- Petr


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

Re: Call for testers for rpmautospec in staging

[Miro Hrončok]

On 14. 04. 20 15:47, Pierre-Yves Chibon wrote:

On Tue, Apr 14, 2020 at 12:46:11PM +0200, Vít Ondruch wrote:


Dne 09. 04. 20 v 15:43 Pierre-Yves Chibon napsal(a):


PS:
  - F32 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f41380eb9
  - F31 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ee46bf2cd
  - F30 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-081a876918




Could be the source package renamed s/python-rpmautospec/rpmautospec/.
The `python-` prefix does not help with the discoverability at all.


Considering that rpmautospec is mostly a python module with two koji plugins and
a small CLI, it seemed appropriate to us to follow the python naming guidelines,
and this is how we understand them.


Being the current de-facto maintainer of the Python Packaging guidelines, let me 
followup on that.


The package produces several installable packages:

- koji-builder-plugin-rpmautospec
- koji-hub-plugin-rpmautospec
- python3-rpmautospec
- rpmautospec
- rpmautospec-rpm-macros

And all of them seem to follow the naming guidelines and conventions.

As for the component/SRPM name, the guidelines are pretty loose here. Both 
"rpmautospec" and "python-rpmautospec" SRPM names are valid depending on how you 
perceive the package.


The Python guidelines explicitly say:

"This rule [using the python- prefix for SRPM] does not apply to applications."

And obviously, the source package does contain both application and other 
things, hence it is really up to the maintainer.


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

Re: Unretire gjots2 (gtk heirarchical note jotter)

[Alexander Ploumistos]

Hello again,

If nobody else steps up to do the review, I'll take care of it later
in the week.
In the meantime, see if you can resolve any of the issues picked up by
rpmlint - there may be some false positives there:

Rpmlint
---
Checking: gjots2-3.1.2-2.fc33.noarch.rpm
  gjots2-3.1.2-2.fc33.src.rpm
gjots2.noarch: W: spelling-error Summary(en_US) organise -> organist,
organism, organize
gjots2.noarch: W: spelling-error %description -l en_US gyachts ->
yachts, g yachts
gjots2.noarch: W: spelling-error %description -l en_US marshall ->
Marshall, marshal, marshals
gjots2.noarch: W: spelling-error %description -l en_US organise ->
organist, organism, organize
gjots2.noarch: W: spelling-error %description -l en_US ccrypt -> crypt, c crypt
gjots2.noarch: W: spelling-error %description -l en_US gpg -> pg, gig, gag
gjots2.noarch: W: spelling-error %description -l en_US openssl -> slope
gjots2.noarch: E: incorrect-fsf-address /usr/bin/docbook2gjots
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2docbook
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2emacs
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2html
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2lpr
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2org
gjots2.noarch: E: incorrect-fsf-address /usr/bin/org2gjots
gjots2.noarch: E: incorrect-fsf-address /usr/share/doc/gjots2/COPYING
gjots2.noarch: W: no-manual-page-for-binary gjots2emacs
gjots2.noarch: W: no-manual-page-for-binary gjots2html.py
gjots2.noarch: W: no-manual-page-for-binary gjots2lpr
gjots2.noarch: W: no-manual-page-for-binary gjots2org
gjots2.noarch: W: no-manual-page-for-binary org2gjots
gjots2.src: W: spelling-error Summary(en_US) organise -> organist,
organism, organize
gjots2.src: W: spelling-error %description -l en_US gyachts -> yachts, g yachts
gjots2.src: W: spelling-error %description -l en_US marshall ->
Marshall, marshal, marshals
gjots2.src: W: spelling-error %description -l en_US organise ->
organist, organism, organize
gjots2.src: W: spelling-error %description -l en_US ccrypt -> crypt, c crypt
gjots2.src: W: spelling-error %description -l en_US gpg -> pg, gig, gag
gjots2.src: W: spelling-error %description -l en_US openssl -> slope
gjots2.src:42: W: mixed-use-of-spaces-and-tabs (spaces: line 3, tab: line 42)
2 packages and 0 specfiles checked; 8 errors, 20 warnings.


Rpmlint (installed packages)

gjots2.noarch: W: spelling-error Summary(en_US) organise -> organist,
organism, organize
gjots2.noarch: W: spelling-error %description -l en_US gyachts ->
yachts, g yachts
gjots2.noarch: W: spelling-error %description -l en_US marshall ->
Marshall, marshal, marshals
gjots2.noarch: W: spelling-error %description -l en_US organise ->
organist, organism, organize
gjots2.noarch: W: spelling-error %description -l en_US ccrypt -> crypt, c crypt
gjots2.noarch: W: spelling-error %description -l en_US gpg -> pg, gig, gag
gjots2.noarch: W: spelling-error %description -l en_US openssl -> slope
gjots2.noarch: W: invalid-url URL: http://bhepple.freeshell.org/gjots

gjots2.noarch: E: incorrect-fsf-address /usr/bin/docbook2gjots
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2docbook
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2emacs
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2html
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2lpr
gjots2.noarch: E: incorrect-fsf-address /usr/bin/gjots2org
gjots2.noarch: E: incorrect-fsf-address /usr/bin/org2gjots
gjots2.noarch: E: incorrect-fsf-address /usr/share/doc/gjots2/COPYING
gjots2.noarch: W: no-manual-page-for-binary gjots2emacs
gjots2.noarch: W: no-manual-page-for-binary gjots2html.py
gjots2.noarch: W: no-manual-page-for-binary gjots2lpr
gjots2.noarch: W: no-manual-page-for-binary gjots2org
gjots2.noarch: W: no-manual-page-for-binary org2gjots
gjots2.noarch: E: invalid-appdata-file /usr/share/appdata/gjots2.appdata.xml
1 packages and 0 specfiles checked; 9 errors, 13 warnings.


The FSF address should be the most straightforward to fix.


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

Re: Call for testers for rpmautospec in staging

[Miro Hrončok]

On 14. 04. 20 16:20, José Abílio Matos wrote:

On Tuesday, 14 April 2020 14.47.15 WEST Pierre-Yves Chibon wrote:

 > Considering that rpmautospec is mostly a python module with two koji plugins

 > and a small CLI, it seemed appropriate to us to follow the python naming

 > guidelines, and this is how we understand them.

 >

 > Pierre

Sure. :-)

But since it has a program associated it is probably a good idea to have

Provides: rpmautospec

since if you are a user you do not care about the python dependency.


There is an "rpmautospec" subpackage already. The discussion is about SRPM name.

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

Re: Call for testers for rpmautospec in staging

[José Abílio Matos]

On Tuesday, 14 April 2020 14.47.15 WEST Pierre-Yves Chibon wrote:
> Considering that rpmautospec is mostly a python module with two koji plugins
> and a small CLI, it seemed appropriate to us to follow the python naming
> guidelines, and this is how we understand them.
> 
> Pierre

Sure. :-)

But since it has a program associated it is probably a good idea to have

Provides: rpmautospec

since if you are a user you do not care about the python dependency.

-- 
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: Call for testers for rpmautospec in staging

[Miro Hrončok]

On 14. 04. 20 15:30, Petr Pisar wrote:

I don't know what specific features of rpmdev-vercmp tool you need, but
version comparison is implemented in rpmvercmp() function of rpm library.


Exactly that, but without the need to use ctypes.

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

[EPEL-devel] Re: Python macro backports for EPEL reviews needed

[Troy Dawson]

Hi Miro,
I've taken a look, but haven't done any testing.

EPEL6 patch - no.  Even if it works, I'd say no.  We're at the last 7
months before EOL and I don't want the EPEL6 stuff to have changes
like this.  I could be outvoted by this, but I believe most of the
other EPEL packagers would feel this way.

EPEL7 patch - This would require some testing.  When we tried to turn
on the python automatic-dependency checking, there were things that
broke on EPEL7 so they never got implemented.  What, or how they
broke, I don't currently know.  I just know that they did, and there
wasn't a big enough demand to debug.  As in zero demand.  Nobody asked
for it in EPEL7, only EPEL8.  So I'm not even sure this would be worth
the testing.  Has anyone asked for this?

EPEL8 patch - We've had requests to have EPEL8 be as close to Fedora,
so I'm in favor of this.
I'm pretty sure the %pycached shouldn't be a problem.
What is %python supposed to resolve to?  To me it looks like
/usr/bin/python ... which there isn't any in RHEL8.  And, I thought
Fedora got rid of it also, in favor of specifically doing python2 or
python3.  Or did that change?

On Tue, Apr 14, 2020 at 5:42 AM Miro Hrončok  wrote:
>
> On 14. 04. 20 13:26, Stephen John Smoogen wrote:
> > Miro.
> >
> > EPEL is interested in Fedora compatibility but has 0 people staffed to it.  
> > I
> > got slammed by the datacentre move and dropped the ball on this. Troy took 
> > over
> > for me last month and has been trying to catch up on all the things we have
> > outstanding. Thank you for reminding us of this outstanding work.
>
> I appreciate that you care. My interest in EPEL is purely "best effort" as I 
> am
> not an EPEL user myself -- I try to not break use cases for people who like to
> maintain packages in Fedora and EPEL alike, but sometimes it's really hard to
> guess what would work for EPEL best when there is no response.
>
> I would very much like to have some "EPEL <-> Python" representative/partner I
> could bring this sort of stuff to.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Call for testers for rpmautospec in staging

[Pierre-Yves Chibon]

On Tue, Apr 14, 2020 at 12:46:11PM +0200, Vít Ondruch wrote:
> 
> Dne 09. 04. 20 v 15:43 Pierre-Yves Chibon napsal(a):
> >
> > PS:
> >  - F32 update: 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f41380eb9
> >  - F31 update: 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ee46bf2cd
> >  - F30 update: 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-081a876918
> >
> >
> 
> Could be the source package renamed s/python-rpmautospec/rpmautospec/.
> The `python-` prefix does not help with the discoverability at all.

Considering that rpmautospec is mostly a python module with two koji plugins and
a small CLI, it seemed appropriate to us to follow the python naming guidelines,
and this is how we understand them.

Pierre


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

Fedora 33 Self-Contained Change proposal: Update Erlang/OTP to version 23

[Ben Cotton]

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

== Summary ==
Update Erlang/OTP to version 23.

== Owner ==
* Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang
SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]]
* Email: lemen...@gmail.com, erl...@lists.fedoraproject.org,
bowlofe...@fedoraproject.org, jcl...@fedoraproject.org

== Detailed Description ==
Upgrade Erlang to version 23 which brings a lot of changes. Just a few
highlights:

* Numerous scalability and performance improvements.
* New modules - pg (pool group) and erpc (enhanced RPC).
* Removed SSL 3.0 support entirely.
* Removed deprecated part of erl_interface API
* An experimental socket backend for TCP and UDP API.
* Even faster SSL/TLS operations.
* Now it's possible to work w/o external EPMD in production-ready applications

Aside from this, we plan to improve quality of Erlang and related
packages. These are shortcomings we want to address:
Besides that we still have a lengthy list of TODOs:

* Every daemon written in Erlang has its own logging solution which
doesn't use neither syslog nor Journald. We should start switching
them to unified logger..
* We should allow D-Bus API via [https://github.com/lizenn/erlang-dbus
erlang-dbus] library or any other recent implementations..
* Further improve [[User:Peter/Erlang_Packaging_Guidelines|Erlang
Packaging Guidelines]] and promote it as the official guideline.
* Switch to rebar3 as a main build tool.
* SELinux rules for main Erlang applications (Ejabberd, CouchDB,
RabbitMQ) are outdated or missing.

== Benefit to Fedora ==
Fedora users, both developers and end-users, will have visible
benefits from using Fedora-provided packages. Namely:

* Improved scalability and robustness.

== Scope ==
* Proposal owners:
** [https://bugzilla.redhat.com/807897 Upgrade Erlang to the latest
version (23.0)].
** We must rebuild every package which requires NIF version (listed
below in the [[#Dependencies|Dependencies]] section) against Erlang
23.x.y.
** Every Erlang daemon's systemd unit must require epmd.socket.
** We need to fill new review request for
[https://github.com/lizenn/erlang-dbus erlang-dbus]
** Upgrade outdated packages:
*** {{package|riak|Riak}}
 {{package|riak|Riak}} has has been retired. We have to re-add it back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
** {{package|erlang-rebar3|rebar3}}
*** Provide/adjust RPM macros for rebar3.
** Package GDB macros for easier coredump debugging (see also
[https://bugzilla.redhat.com/show_bug.cgi?id=663253 this ticket]).
* Other developers: N/A
* Release engineering: TBA
* Policies and guidelines:
** We should promote officially
[[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]].
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
* Every Erlang upgrade requires the rebuilding of modules which
contains [http://www.erlang.org/doc/reference_manual/ports.html ports]
or [http://www.erlang.org/doc/tutorial/nif.html NIFs], and we will
rebuild all such modules in Fedora. However if a user has some
additional modules not available in a Fedora repository, then these
modules must be rebuilt manually.
* So-called [http://erlang.org/doc/man/HiPE_app.html HiPE] continues
to deteriorate. In this version it's barely functional and likely is
going to be removed in the next one.

== How To Test ==

* Ensure that high-grade Erlang applications are still working:
(see wiki)

* Collect feedback from volunteers regarding their experience with
this Erlang/OTP version

== User Experience ==
Users will get more robust, scalable, and fast Erlang applications.

== Dependencies ==

The following packages must be rebuilt:
(see wiki)

== Contingency Plan ==
* Contingency mechanism: None necessary. Instead of falling back to
the previous version we should fix existing packages in order to help
the Community. We should also monitor upstream development process for
potentially discovered issues and proactively apply patches (as we
already did with [[Features/Erlang_R14|Erlang R14]],
[[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang
R16]], [[Changes/BetterErlangSupport|Erlang 17]],
[[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]],
[[Changes/Erlang_20|Erlang 20]], [[Changes/Erlang_21|Erlang 21]] and
[[Changes/Erlang_22|Erlang 22]]). It should be noted that this change
consists from an independent or loosely coupled smaller changes. If we
fail to deliver some changes in time, we should reschedule these exact
changes to the future Fedora release while keeping already implemented
ones.
* Contingency deadline: N/A
* Blocks release? N/A
* Blocks product? N/A

== Documentation ==
* [https://www.erlang.org/news/138 Erlang/OTP 23 Release Candidate 2
release notes]

== Release Notes ==

Erlang/OTP 23.0 is available in Fedora 33.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red 

Fedora 33 Self-Contained Change proposal: Update Erlang/OTP to version 23

[Ben Cotton]

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

== Summary ==
Update Erlang/OTP to version 23.

== Owner ==
* Name: [[User:Peter|Peter Lemenkov]], [[SIGs/Erlang|Fedora Erlang
SIG]], [[User:bowlofeggs|Randy Barlow]], [[User:jcline|Jeremy Cline]]
* Email: lemen...@gmail.com, erl...@lists.fedoraproject.org,
bowlofe...@fedoraproject.org, jcl...@fedoraproject.org

== Detailed Description ==
Upgrade Erlang to version 23 which brings a lot of changes. Just a few
highlights:

* Numerous scalability and performance improvements.
* New modules - pg (pool group) and erpc (enhanced RPC).
* Removed SSL 3.0 support entirely.
* Removed deprecated part of erl_interface API
* An experimental socket backend for TCP and UDP API.
* Even faster SSL/TLS operations.
* Now it's possible to work w/o external EPMD in production-ready applications

Aside from this, we plan to improve quality of Erlang and related
packages. These are shortcomings we want to address:
Besides that we still have a lengthy list of TODOs:

* Every daemon written in Erlang has its own logging solution which
doesn't use neither syslog nor Journald. We should start switching
them to unified logger..
* We should allow D-Bus API via [https://github.com/lizenn/erlang-dbus
erlang-dbus] library or any other recent implementations..
* Further improve [[User:Peter/Erlang_Packaging_Guidelines|Erlang
Packaging Guidelines]] and promote it as the official guideline.
* Switch to rebar3 as a main build tool.
* SELinux rules for main Erlang applications (Ejabberd, CouchDB,
RabbitMQ) are outdated or missing.

== Benefit to Fedora ==
Fedora users, both developers and end-users, will have visible
benefits from using Fedora-provided packages. Namely:

* Improved scalability and robustness.

== Scope ==
* Proposal owners:
** [https://bugzilla.redhat.com/807897 Upgrade Erlang to the latest
version (23.0)].
** We must rebuild every package which requires NIF version (listed
below in the [[#Dependencies|Dependencies]] section) against Erlang
23.x.y.
** Every Erlang daemon's systemd unit must require epmd.socket.
** We need to fill new review request for
[https://github.com/lizenn/erlang-dbus erlang-dbus]
** Upgrade outdated packages:
*** {{package|riak|Riak}}
 {{package|riak|Riak}} has has been retired. We have to re-add it back.
*** {{package|ejabberd|Ejabberd}}
*** {{package|rabbitmq-server|RabbitMQ}}.
*** {{package|couchdb|CouchDB}}
** {{package|erlang-rebar3|rebar3}}
*** Provide/adjust RPM macros for rebar3.
** Package GDB macros for easier coredump debugging (see also
[https://bugzilla.redhat.com/show_bug.cgi?id=663253 this ticket]).
* Other developers: N/A
* Release engineering: TBA
* Policies and guidelines:
** We should promote officially
[[User:Peter/Erlang_Packaging_Guidelines|Erlang Packaging
Guidelines]].
* Trademark approval: N/A (not needed for this Change)

== Upgrade/compatibility impact ==
* Every Erlang upgrade requires the rebuilding of modules which
contains [http://www.erlang.org/doc/reference_manual/ports.html ports]
or [http://www.erlang.org/doc/tutorial/nif.html NIFs], and we will
rebuild all such modules in Fedora. However if a user has some
additional modules not available in a Fedora repository, then these
modules must be rebuilt manually.
* So-called [http://erlang.org/doc/man/HiPE_app.html HiPE] continues
to deteriorate. In this version it's barely functional and likely is
going to be removed in the next one.

== How To Test ==

* Ensure that high-grade Erlang applications are still working:
(see wiki)

* Collect feedback from volunteers regarding their experience with
this Erlang/OTP version

== User Experience ==
Users will get more robust, scalable, and fast Erlang applications.

== Dependencies ==

The following packages must be rebuilt:
(see wiki)

== Contingency Plan ==
* Contingency mechanism: None necessary. Instead of falling back to
the previous version we should fix existing packages in order to help
the Community. We should also monitor upstream development process for
potentially discovered issues and proactively apply patches (as we
already did with [[Features/Erlang_R14|Erlang R14]],
[[Features/Erlang_R15|Erlang R15]], [[Features/Erlang_R16|Erlang
R16]], [[Changes/BetterErlangSupport|Erlang 17]],
[[Changes/Erlang_18|Erlang 18]], [[Changes/Erlang_19|Erlang 19]],
[[Changes/Erlang_20|Erlang 20]], [[Changes/Erlang_21|Erlang 21]] and
[[Changes/Erlang_22|Erlang 22]]). It should be noted that this change
consists from an independent or loosely coupled smaller changes. If we
fail to deliver some changes in time, we should reschedule these exact
changes to the future Fedora release while keeping already implemented
ones.
* Contingency deadline: N/A
* Blocks release? N/A
* Blocks product? N/A

== Documentation ==
* [https://www.erlang.org/news/138 Erlang/OTP 23 Release Candidate 2
release notes]

== Release Notes ==

Erlang/OTP 23.0 is available in Fedora 33.

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red 

Re: Call for testers for rpmautospec in staging

[Petr Pisar]

On Tue, Apr 14, 2020 at 03:14:59PM +0200, Miro Hrončok wrote:
> On 14. 04. 20 15:04, Nils Philippsen wrote:
> > > Or even running `rpmdev-vercmp` and `rpm --eval` with subprocess:
> > I'd rather not pull in rpmdevtools -- which depends on Perl and a
> > couple 3rd party Perl packages.;)
> 
> Out of the frying pan and into the fire. Sorry, I forgot that rpmdev-vercmp
> is not part of rpm.
> 
I don't know what specific features of rpmdev-vercmp tool you need, but
version comparison is implemented in rpmvercmp() function of rpm library.
I even have a tiny Perl wrapper, perl-RPM-VersionCompare, for that :)

-- Petr


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

Re: Call for testers for rpmautospec in staging

[Miro Hrončok]

On 14. 04. 20 15:04, Nils Philippsen wrote:

Or even running `rpmdev-vercmp` and `rpm --eval` with subprocess:

I'd rather not pull in rpmdevtools -- which depends on Perl and a
couple 3rd party Perl packages.;)


Out of the frying pan and into the fire. Sorry, I forgot that rpmdev-vercmp is 
not part of rpm.


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

Re: Qt 5.14.2 coming to rawhide

[Sandro Mani]

Is this related to the update?


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

confgui/confgui.h:71:10: fatal error: QString: No such file or directory
   71 | #include 

(I don't maintain recoll, but this started to show up in our Python 
3.9 Copr.)

Likely https://bugzilla.redhat.com/show_bug.cgi?id=1823118
___
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: Call for testers for rpmautospec in staging

[Neal Gompa]

On Tue, Apr 14, 2020 at 9:06 AM Nils Philippsen  wrote:
>
> On Tue, 2020-04-14 at 13:58 +0200, Miro Hrončok wrote:
> > On 14. 04. 20 13:39, Nils Philippsen wrote:
> > > So, to make this more robust against problems like you described,
> > > we
> > > should decouple what's run in the build root from a specific minor
> > > version of Python and the rpm Python package (and remove the
> > > superfluous Koji dependency). This shouldn't be much work, the
> > > biggest
> > > piece is probably to make it get by without using the rpm Python
> > > package (for comparing EVRs and to expand macros), but a tiny
> > > ctypes
> > > wrapper around rpmlib should solve this for us.
> >
> > Or even running `rpmdev-vercmp` and `rpm --eval` with subprocess:
>
> I'd rather not pull in rpmdevtools -- which depends on Perl and a
> couple 3rd party Perl packages. ;)
>
> One thing I missed in my previous mail was that we already shell out to
> rpmspec ("rpm --specfile ...") to query the epoch/version of the spec
> file, but that should be okay, too -- it's part of rpm-build which we
> need for building the SRPM at that point anyway.
>

For what its worth, I want to get rid of the Perl dependency. I just
have to decide which Python reimplementation of spectool to put in
there... :)



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for testers for rpmautospec in staging

[Nils Philippsen]

On Tue, 2020-04-14 at 13:58 +0200, Miro Hrončok wrote:
> On 14. 04. 20 13:39, Nils Philippsen wrote:
> > So, to make this more robust against problems like you described,
> > we
> > should decouple what's run in the build root from a specific minor
> > version of Python and the rpm Python package (and remove the
> > superfluous Koji dependency). This shouldn't be much work, the
> > biggest
> > piece is probably to make it get by without using the rpm Python
> > package (for comparing EVRs and to expand macros), but a tiny
> > ctypes
> > wrapper around rpmlib should solve this for us.
> 
> Or even running `rpmdev-vercmp` and `rpm --eval` with subprocess:

I'd rather not pull in rpmdevtools -- which depends on Perl and a
couple 3rd party Perl packages. ;)

One thing I missed in my previous mail was that we already shell out to
rpmspec ("rpm --specfile ...") to query the epoch/version of the spec
file, but that should be okay, too -- it's part of rpm-build which we
need for building the SRPM at that point anyway.

Nils
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:  D0C1 1576 CDA6 5B6E BBAE  95B2 7D53 7FCA E9F6 395D
old:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
___
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

Renaming nodejs-yarn -> yarnpkg

[Zuzana Svetlikova]

Hi,

I submitted a rename review[1] for nodejs-yarn to be renamed to yarnpkg to
make it more consistent with other
distros and upstream. If you have any comments or this change causes you
any issues, feel free to speak up.

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

Thanks

Zuzka
___
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: Qt 5.14.2 coming to rawhide

[Miro Hrončok]

On 07. 04. 20 6:07, Rex Dieter wrote:

Rex Dieter wrote:


FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in-
progress being done in side tag f33-build-side-21031

I figure it'll take at least a few days to get the core bits and all
dependencies rebuilt.  Will provide status updates as warranted.

Fist batch of builds completed, bodhi update:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-641e69f08c

Hope I did that right, with:
bodhi updates new --from-tag ...
according tohttps://docs.fedoraproject.org/en-US/rawhide-gating/multi-builds/

There were a handful of failures...

Is this related to the update?

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

confgui/confgui.h:71:10: fatal error: QString: No such file or directory
   71 | #include 

(I don't maintain recoll, but this started to show up in our Python 3.9 Copr.)

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

[EPEL-devel] Re: Python macro backports for EPEL reviews needed

[Miro Hrončok]

On 14. 04. 20 13:26, Stephen John Smoogen wrote:

Miro.

EPEL is interested in Fedora compatibility but has 0 people staffed to it.  I 
got slammed by the datacentre move and dropped the ball on this. Troy took over 
for me last month and has been trying to catch up on all the things we have 
outstanding. Thank you for reminding us of this outstanding work.


I appreciate that you care. My interest in EPEL is purely "best effort" as I am 
not an EPEL user myself -- I try to not break use cases for people who like to 
maintain packages in Fedora and EPEL alike, but sometimes it's really hard to 
guess what would work for EPEL best when there is no response.


I would very much like to have some "EPEL <-> Python" representative/partner I 
could bring this sort of stuff to.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

[EPEL-devel] Re: Request EPEL8 branch for "tinyfugue"

[Justin Coffman]

I am not yet a packager, but I would love to help out!

-Original Message-
From: Felix Schwarz  
Sent: Tuesday, April 14, 2020 7:57 AM
To: EPEL Development List ; Justin Coffman 

Subject: [EPEL-devel] Re: Request EPEL8 branch for "tinyfugue"

Hi Justin,

Am 12.04.20 um 03:40 schrieb Justin Coffman:
> There’s a bug currently open requesting that “tinyfugue” be packaged for EPEL 
> 8.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1762158
> 
> There hasn’t been any response to the original requestor since it was 
> opened in October. It’d be great if someone could help out.

As far as I can see Kellin (bug reporter) became package admin so maybe he can 
push the EPEL8 branch. I assume Petr does not want to maintain additional EPEL 
branches.

Are you a Fedora/EPEL packager already? Maybe we can help you scratching your 
own itch?

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

Re: Fedora 32 drop old (<1.2) TLS protocol and with evolution you get "Error performing TLS handshake: A packet with illegal or unsupported version was received."

[Petr Pisar]

On Tue, Apr 14, 2020 at 01:43:55PM +0200, Dario Lesca wrote:
> Il giorno mar, 07/04/2020 alle 23.01 +0200, Dario Lesca ha scritto:
> > > Please file a bug.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1821934
> 
> There is some news for this issue?
> Will fedora 32 come out with default TLS >=1.2 ?
> Thank for reply
> 
Disabling TLS < 1.2 is planned for Fedora 33
.

-- Petr


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

Re: Call for testers for rpmautospec in staging

[Miro Hrončok]

On 14. 04. 20 13:39, Nils Philippsen wrote:

So, to make this more robust against problems like you described, we
should decouple what's run in the build root from a specific minor
version of Python and the rpm Python package (and remove the
superfluous Koji dependency). This shouldn't be much work, the biggest
piece is probably to make it get by without using the rpm Python
package (for comparing EVRs and to expand macros), but a tiny ctypes
wrapper around rpmlib should solve this for us.


Or even running `rpmdev-vercmp` and `rpm --eval` with subprocess:

Inspiration: 
https://github.com/hroncok/mini-mass-rebuild/blob/9759e77/obsolete_packages.py#L40-L52


And: 
https://github.com/fedora-python/pyp2rpm/blob/33ab6c0c/pyp2rpm/utils.py#L152-L162



To me, that's good enough. Porting the pieces that have to run inside
the build root to e.g. shell really wouldn't make them more robust, but
just change one dependency which may not break for another.


Sure. Running on Python (stdlib only) is good enough.

Thanks for the update, I really like where this is going.

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

Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Miro Hrončok]

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

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

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

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

Package  (co)maintainers   Status Change

CPUFreqUtilityorphan   1 weeks ago
GConf2alexl, caillon, caolanm, 1 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, ssp, walters
GREYCstorationorphan   1 weeks ago
abcm2ps   orphan   1 weeks ago
adapta-gtk-theme  orphan   1 weeks ago
afpfs-ng  orphan   1 weeks ago
antlr4gil, jkastner, lef, mizdebsk,1 weeks ago
  orphan
apache-commons-dbutilsmizdebsk, orphan 1 weeks ago
apache-commons-email  mizdebsk, orphan 1 weeks ago
apache-commons-jcijjelen, orphan   1 weeks ago
apache-commons-jcscquad, jjelen, orphan2 weeks ago
apanov-edrip-fontsfrixxon, orphan  1 weeks ago
apbs  orphan, rathann  1 weeks ago
artha orphan   1 weeks ago
avalon-framework  jerboaa, jjelen, mizdebsk,   2 weeks ago
  orphan
avr-gdb   giallu, orphan, trondd   1 weeks ago
batik jvanek, mizdebsk, orphan,1 weeks ago
  sergiomb
biboumi   jcline, orphan   2 weeks ago
bmake orphan   1 weeks ago
bval  jjelen, orphan   1 weeks ago
bygfoot   orphan   1 weeks ago
cassandra-java-driver hhorak, jjanco, orphan   1 weeks ago
castorlef, orphan  1 weeks ago
catimgorphan   1 weeks ago
cdpr  orphan   1 weeks ago
ckermit   orphan   1 weeks ago
classloader-leak-test-framework   orphan, praiskup 1 weeks ago
cmyktool  orphan   1 weeks ago
cog   orphan   1 weeks ago
containersorphan   3 weeks ago
coriander dajt, orphan 1 weeks ago
cpptasks  orphan   5 weeks ago
dateshift orphan   1 weeks ago
dibbler   orphan   1 weeks ago
docco nodejs-sig, orphan, patches  1 weeks ago
drbd  orphan   1 weeks ago
dsi   orphan   1 weeks ago
echoping  orphan   1 weeks ago
eclipse-avr   orphan   1 weeks ago
eclipse-egit-github   eclipse-sig, orphan  1 weeks ago
eclipse-m2e-core  eclipse-sig, galileo,1 weeks ago
  mizdebsk, orphan
eclipse-mylyn arobinso, eclipse-sig,   1 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-photran   akurtakov, eclipse-sig, orphan   1 weeks ago
eclipse-ptp   eclipse-sig, jjohnstn,   1 weeks ago
  kdaniel, orphan
eclipse-remoteeclipse-sig, orphan  

[EPEL-devel] Re: Request EPEL8 branch for "tinyfugue"

[Felix Schwarz]

Hi Justin,

Am 12.04.20 um 03:40 schrieb Justin Coffman:
> There’s a bug currently open requesting that “tinyfugue” be packaged for EPEL 
> 8.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1762158
> 
> There hasn’t been any response to the original requestor since it was opened
> in October. It’d be great if someone could help out.

As far as I can see Kellin (bug reporter) became package admin so maybe he can
push the EPEL8 branch. I assume Petr does not want to maintain additional EPEL
branches.

Are you a Fedora/EPEL packager already? Maybe we can help you scratching your
own itch?

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

Fedora 32 drop old (<1.2) TLS protocol and with evolution you get "Error performing TLS handshake: A packet with illegal or unsupported version was received."

[Dario Lesca]

Il giorno mar, 07/04/2020 alle 23.01 +0200, Dario Lesca ha scritto:
> > Please file a bug.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1821934

There is some news for this issue?
Will fedora 32 come out with default TLS >=1.2 ?
Thank for reply


-- 
Dario Lesca
(inviato dal mio Linux Fedora 31 Workstation)
___
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: Call for testers for rpmautospec in staging

[Nils Philippsen]

Hey Miro!

On Fri, 2020-04-10 at 11:01 +0200, Miro Hrončok wrote:
> On 10. 04. 20 1:50, Miro Hrončok wrote:
> > On 09. 04. 20 23:57, Miro Hrončok wrote:
> > > On 09. 04. 20 20:45, Pierre-Yves Chibon wrote:
> > > > I actually cannot comment on this, it may be worth opening a
> > > > koji ticket to ask
> > > > if this is the case or not and if it is if they can think of a
> > > > way to deal with
> > > > this.
> > > 
> > > I plan to test this in staging and follow up on that, but
> > > possibly after Easter.
> > 
> > I was curious:
> > 
> > https://koji.stg.fedoraproject.org/koji/taskinfo?taskID=90028113

[snipped errors from broken Python 3rd party packages]

> So there are 2 reasonable things I think that can be done apart from
> rewriting rpmautospec into Rust ;)

It's a little late for April Fools. :)

[snipped the "special case buildSRPMFromSCM for side tag builds"
approach]

> ## Move (most of) rpmautospec outside of the mock chroot
> 
> Another solution I can think of is that the koji-builder-plugin-
> rpmautospec 
> package does all the nice things like figure out what to inject into
> the spec 
> file and prepares everything for needed for rpmautospec *outside of
> the mock 
> chroot*.
>
> rpmautospec than in fact would only be responsible of actually
> putting the 
> information into the specfile without using all the 3rd party Python
> libraries.
> It would be a simple script (see fedpkg-minimal that exists for this
> very 
> reason) -- keeping it in written in Python remain an option (as long
> as it only 
> uses stdlib and doesn't live in site-packages), but making it Bash
> (like 
> fedpkg-minimal) would be even less fragile.
>
> However, what are the reasons to determine the spec content from
> within the 
> buildroot? Does it heavily depend on values of macros like %fedora or
> %dist?
> 
> What parts of the procedure are safe to do from a different system
> and what 
> needs to be done from within?
> 
> Pros:
> 
> 1. Much more robust solution, smaller package footprint in
> buildSRPMFromSCM 
> means smaller "bungle surface" (like "attack surface" but without the
> ill will).
> 
> Cons:
> 
> 2. Significant (design) changes in rpmautospec needed.
> 3. I don't know the exact reasons rpmautospec runs from within the
> chroot.

I think rpmautospec separates concerns between what has to be done in
the build root vs. what can be done outside pretty good already. ;)

Let me back up a little:

The reason rpmautospec does anything in the build root at all is
because the code that computes the "next release" value has to know for
which Fedora version (or more precisely, the %dist tag) the build in
question is intended: if at all possible, the EVR about to be built
should fit within that of the latest builds in the same or older Fedora
versions on the one hand, and newer Fedora versions on the other.

Unfortunately (for rpmautospec), Koji doesn't really care about the
Fedora or EPEL version it's building for, all it seems to know is tags
and how they're derived from each other. The dist tag is only set in
the build root, by /usr/lib/rpm/macros.d/macros.dist from the fedora-
release-common package.

Fortunately, rpmautospec already does very little in the build root:
The plugin queries Koji outside (this is where the one 3rd party Python
package dep comes from) and stores the information gathered (latest
build EVRs for each dist tag) as git tags. The code run in the build
root computes the next release using the tags (dep on git-core), and
with that generates the changelog (which needs info about the current
and historic build EVRs).

So, to make this more robust against problems like you described, we
should decouple what's run in the build root from a specific minor
version of Python and the rpm Python package (and remove the
superfluous Koji dependency). This shouldn't be much work, the biggest
piece is probably to make it get by without using the rpm Python
package (for comparing EVRs and to expand macros), but a tiny ctypes
wrapper around rpmlib should solve this for us.

To me, that's good enough. Porting the pieces that have to run inside
the build root to e.g. shell really wouldn't make them more robust, but
just change one dependency which may not break for another.

Also, even if the worst came to the worst, say a severily broken Python
or git-core package has snuck its way into the build roots, and all
people with the power to untag these went on vacation, then any
packager can easily unblock their build by temporarily reverting to a
manually set release and changelog, the plugin will just go out of the
way in this case.

Nils
-- 
Nils Philippsen"Those who would give up Essential Liberty to
Software Engineer   purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:  D0C1 1576 CDA6 5B6E BBAE  95B2 7D53 7FCA E9F6 395D
old:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

CPE Weekly: 2020-04-14

[Aoife Moloney]

# CPE Weekly: 2020-04-14
---
title: CPE Weekly status email
tags: CPE Weekly, email
---

Hi All,

Apologies for the delayed weekly mail, I enjoyed a lovely four-day
weekend with my family over Easter which was important and didn't get
around to sending this email.

The upside is you get two emails from me this week instead :)



Background:
The Community Platform Engineering group is the Red Hat team combining
IT and release engineering from Fedora and CentOS.Check out our teams
info here https://docs.fedoraproject.org/en-US/cpe/


## GitForge Updates
* Initial conversations have started with GitLab to investigate
options and weight them against more refined requirements to make sure
we reach the best possible outcome
* We are still engaging with Fedora Council
https://pagure.io/Fedora-Council/tickets/issue/292
* We are also engaging with the CentOS board too
* And we are looking at ways to have open conversations/Q sessions
in public forums too as we move through this journey.



## Fedora Updates
* F32 release first go/no-go meeting is scheduled for this week to
review the estimated release date of 21st April
* Calendar for meetings here
https://apps.fedoraproject.org/calendar/Fedora%20release/
* F32 release schedule here https://fedoraproject.org/wiki/Releases/32/Schedule





### Data Centre Move
* CommuniShift is now down until May 8th est. to facilitate the data
centre move that has now officially begun.
* Please see our list of affected https://hackmd.io/hpYYJQRjQy-oHxUS7IonIA
* Our first few sets of hardware have been deracked and are awaiting
collection from PHX2 this week.
* Please check our schedule here - we are on Week 06
https://hackmd.io/R3EkjzVyTG2TYwQvkfzYrA


### AAA Replacement
* The team are planning phase two of the replacement which will target
UX/UI improvements,



### CI/CD

* rpmautospec
* Call for testers has been sent to the devel-announce list:
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/LWE4URIRWVTEZKXKP7QOK5JXFNVJRUNW/
* Documentation is also being refined on:
* How it works
* What are its peculiarities
* How to opt-in
* What is working and what isn't yet
* What remains to do before this gets pushed to production
* Thank you for your feedback!






### Sustaining Team
* Mbbox Upgrade
* The team are making good progress on the koji-builder & koji-hub
CRD https://github.com/fedora-infra/mbbox/pull/20
* They also have resolved the issue with PVC in the mbox-operator
https://github.com/fedora-infra/mbbox/pull/23
* We are now looking into CI support and the work that this will involve
* Bodhi
* Investigation database lockups, seems related to celery worker
not completing their tasks
* Working on a 5.3 release
* Releng
* fedscm-admin 1.0.13 released
* Future openh264 composes will use ODCS, script is added to releng repo
* Infra
* The daily standup the team has has helped a lot with managing
infra tickets - they are down to 99 tickets!
* Mass update of stg and prod
* Please note you may experience some Kojira slowness
* New review-stats application deployed -
(https://fedoraproject.org/PackageReviewStatus/)






## CentOS Updates

### CentOS
* CentOS CI is stable and all working fine
* Investigation for cloud vms addition to cico is also underway
* RHEL 8.1 batch update 07-Apr






### CentOS Stream
* We have now ~200 packages built in CentOS Stream & we expect a few
hundred more to become available to us soon!
* The team are also still working on general compose config, koji tag
& housekeeping :)













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


Have a great weekend!

Aoife


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

-

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

[EPEL-devel] Re: Python macro backports for EPEL reviews needed

[Stephen John Smoogen]

On Tue, 14 Apr 2020 at 06:08, Miro Hrončok  wrote:

> On 02. 01. 20 15:36, Miro Hrončok wrote:
> > Hey EPEL experts. Could you please have a look at:
> >
> > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/13
> > https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14
> >
> > Thanks.
>
> Is EPEL interested in Fedora compatibility? Or shall I stop caring and
> close them?
>
>
Miro.

EPEL is interested in Fedora compatibility but has 0 people staffed to it.
I got slammed by the datacentre move and dropped the ball on this. Troy
took over for me last month and has been trying to catch up on all the
things we have outstanding. Thank you for reminding us of this outstanding
work.


> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
>


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

Fedora-Cloud-31-20200414.0 compose check report

[Fedora compose checker]

No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Call for testers for rpmautospec in staging

[Vít Ondruch]

Dne 09. 04. 20 v 15:43 Pierre-Yves Chibon napsal(a):
>
> PS:
>  - F32 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f41380eb9
>  - F31 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-3ee46bf2cd
>  - F30 update: https://bodhi.fedoraproject.org/updates/FEDORA-2020-081a876918
>
>

Could be the source package renamed s/python-rpmautospec/rpmautospec/.
The `python-` prefix does not help with the discoverability at all.


Vít




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

Re: Fedpkg: (scratch)-build forked repo directly in Koji

[clime]

On Tue, 14 Apr 2020 at 12:05, Vít Ondruch  wrote:
>
>
> Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a):
>
> TLDR: Is $SUBJ function reasonable to implement in fedpkg?
>
> Hi,
>
> some time ago, fedpkg issue tracker got a request [1] for method, that allows 
> direct builds. That means without sending srpms via "--srpm" argument. 
> Currently, user's changes can be built:
>
> fedpkg scratch-build --srpm
>
> This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg sends just 
> (git) hash id to koji. But fedpkg needs modification to send a right hash id 
> for user changes. Additionally, koji doesn't allow building hash ids from 
> forked repos.
>
>
> Even if this was possible, that would also mean that the sources have to be 
> uploaded into look-a-side cache. Then it very much depend what is the content 
> of the PR. If I am building Ruby nightly snapshots, I don't think it is fair 
> to pollute look-a-side cache with them and I am afraid this is not the only 
> case. I wish we had a way to override the look-a-side cache somehow 

If I understand correctly, this would have to be done, if sources
changed only, right? I.e. if there is a change just in patch or a spec
file, the sources could be fetched from the main project.

Should there be a possibility to upload sources for a fork that would
then be moved to the main project when the pull request is merged?

>
>
> Vít
>
>
> The question to the community. Is reasonable to implement this way of 
> building scratches? --srpm argument would still work as previously.
>
> There is a suggested PR for this here: [2]. It is not completed yet.
>
> Risks:
> * approach could confuse users. Users are used to work with fedpkg 
> differently.
> * koji would have to allow these builds
> * more code complexity; currently there is a way how to reach your result 
> even without this function
>
> Thanks
> Ondrej
>
> [1] https://pagure.io/fedpkg/issue/282
> [2] https://pagure.io/fedpkg/pull-request/390
>
> ___
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Peter Robinson]

> On 14. 04. 20 11:06, Miro Hrončok wrote:
> > The following packages are orphaned...
> >
> > GConf2alexl, caillon, caolanm, 1 weeks 
> > ago
>
> firefox (maintained by: alexl, caolanm, gecko-maint, jgrulich, kalev, 
> kengert,
> mbarnes, rhughes, rstrode, sharkcz, stransky, ueno, xhorak)
> firefox-75.0-1.fc33.src requires pkgconfig(gconf-2.0) = 3.2.6
>
> thunderbird (maintained by: alexl, caolanm, gecko-maint, johnp, 
> kalev, kengert,
> mbarnes, rhughes, rstrode, ssp, stransky, ueno, xhorak)
> thunderbird-68.7.0-1.fc33.src requires GConf2-devel = 
> 3.2.6-27.fc31
>
> icecat (maintained by: jenslody, kengert, sagitter)
> icecat-68.7.0-1.rh1.fc33.src requires pkgconfig(gconf-2.0) = 
> 3.2.6
>
>
> This seems like a forgotten dependency. At least thunderbird builds fine 
> without
> GConf2.

I bet it was a leftover from the migration to gsettings with the
gsettings-data-convert script, I suspect all the runtime deps
(anaconda too) is around this and can probably be dropped.

> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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

[EPEL-devel] Re: Python macro backports for EPEL reviews needed

[Miro Hrončok]

On 02. 01. 20 15:36, Miro Hrončok wrote:

Hey EPEL experts. Could you please have a look at:

https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/13
https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/14

Thanks.


Is EPEL interested in Fedora compatibility? Or shall I stop caring and close 
them?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org

Re: Fedpkg: (scratch)-build forked repo directly in Koji

[Vít Ondruch]

Dne 14. 04. 20 v 0:13 Ondrej Nosek napsal(a):
> TLDR: Is $SUBJ function reasonable to implement in fedpkg?
>
> Hi,
>
> some time ago, fedpkg issue tracker got a request [1] for method, that
> allows direct builds. That means without sending srpms via "--srpm"
> argument. Currently, user's changes can be built:
>
>     fedpkg scratch-build --srpm
>
> This way, fedpkg sends srpm file to koji. Without "--srpm", fedpkg
> sends just (git) hash id to koji. But fedpkg needs modification to
> send a right hash id for user changes. Additionally, koji doesn't
> allow building hash ids from forked repos.


Even if this was possible, that would also mean that the sources have to
be uploaded into look-a-side cache. Then it very much depend what is the
content of the PR. If I am building Ruby nightly snapshots, I don't
think it is fair to pollute look-a-side cache with them and I am afraid
this is not the only case. I wish we had a way to override the
look-a-side cache somehow 


Vít


> The question to the community. Is reasonable to implement this way of
> building scratches? --srpm argument would still work as previously.
>
> There is a suggested PR for this here: [2]. It is not completed yet.
>
> Risks:
> * approach could confuse users. Users are used to work with fedpkg
> differently.
> * koji would have to allow these builds
> * more code complexity; currently there is a way how to reach your
> result even without this function
>
> Thanks
> Ondrej
>
> [1] https://pagure.io/fedpkg/issue/282
> [2] https://pagure.io/fedpkg/pull-request/390
>
> ___
> 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

[Bug 1823158] perl-App-cpm-0.991 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-App-cpm-0.991-1.fc33
 Resolution|--- |RAWHIDE
Last Closed||2020-04-14 10:04:08




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Miro Hrončok]

On 14. 04. 20 11:38, Miro Hrončok wrote:

On 14. 04. 20 11:24, Vít Ondruch wrote:


Dne 14. 04. 20 v 11:06 Miro Hrončok napsal(a):


rubygem-ruby2ruby orphan   1
weeks ago



It seems that the "take" button on Pagure does not work reliably. Last
week, I have picked up several packages including this one just to find
later that I actually did not picked them up. Weird.


I've just checked and it seems I needed to click it twice to make it work.


BTW I've gave the rubygem-ruby2ruby package to you when I was done playing with 
the button.


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

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Miro Hrončok]

On 14. 04. 20 11:24, Vít Ondruch wrote:


Dne 14. 04. 20 v 11:06 Miro Hrončok napsal(a):


rubygem-ruby2ruby orphan   1
weeks ago



It seems that the "take" button on Pagure does not work reliably. Last
week, I have picked up several packages including this one just to find
later that I actually did not picked them up. Weird.


I've just checked and it seems I needed to click it twice to make it work.

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

[Bug 1823158] perl-App-cpm-0.991 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Sandro Mani]

I just took orphan   1 weeks ago


laszip devrim, orphan   5 weeks ago
liblas    devrim, orphan 5 weeks ago
spatialite-gui    orphan 1 weeks ago


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

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Miro Hrončok]

On 14. 04. 20 11:06, Miro Hrončok wrote:

The following packages are orphaned...

GConf2    alexl, caillon, caolanm, 1 weeks ago


	firefox (maintained by: alexl, caolanm, gecko-maint, jgrulich, kalev, kengert, 
mbarnes, rhughes, rstrode, sharkcz, stransky, ueno, xhorak)

firefox-75.0-1.fc33.src requires pkgconfig(gconf-2.0) = 3.2.6

	thunderbird (maintained by: alexl, caolanm, gecko-maint, johnp, kalev, kengert, 
mbarnes, rhughes, rstrode, ssp, stransky, ueno, xhorak)

thunderbird-68.7.0-1.fc33.src requires GConf2-devel = 
3.2.6-27.fc31

icecat (maintained by: jenslody, kengert, sagitter)
icecat-68.7.0-1.rh1.fc33.src requires pkgconfig(gconf-2.0) = 
3.2.6


This seems like a forgotten dependency. At least thunderbird builds fine without 
GConf2.


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

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Miro Hrončok]

On 14. 04. 20 11:18, Dan Horák wrote:

patrikopravil: jruby pbrobinson: GConf2, jruby

Why am I listed against jruby?

you should search for your name in the full report

jruby blocks rubygem-json and

xapian-bindings (maintained by: denisarnaud, drago01,
pbrobinson) xapian-bindings-1.4.14-3.fc33.src requires rubygem-json =
2.3.0-201.fc32


Note that it seem to me that several Ruby packages have jruby shebangs in doc 
subpackages, mostly generating noise here. However I'm not sure about this 
assumption, the real reason why rubygem-json-doc and rubygem-json_pure-doc 
require /usr/bin/jruby is unknown to me. CCing Vít.


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

[Bug 1823020] perl-Net-SSH2-0.71 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Net-SSH2-0.71-1.fc33
 Resolution|--- |RAWHIDE
Last Closed||2020-04-14 09:27:36




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers (incl. GConf2, keybinder3, orangefs)

[Vít Ondruch]

Dne 14. 04. 20 v 11:18 Dan Horák napsal(a):
> On Tue, 14 Apr 2020 10:12:35 +0100
> Peter Robinson  wrote:
>
>> On Tue, Apr 14, 2020 at 10:07 AM Miro Hrončok 
>> wrote:
>>> The following packages are orphaned and will be retired when they
>>> are orphaned for six weeks, unless someone adopts them. If you know
>>> for sure that the package should be retired, please do so now with
>>> a proper reason:
>>> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>>>
>>> Note: If you received this mail directly you (co)maintain one of
>>> the affected packages or a package that depends on one. Please
>>> adopt the affected package or retire your depending package to
>>> avoid broken dependencies, otherwise your package will be retired
>>> when the affected package gets retired.
>>>
>>> Request package ownership via the *Take* button in he left column on
>>> https://src.fedoraproject.org/rpms/
>>>
>>> Full report available at:
>>> https://churchyard.fedorapeople.org/orphans-2020-04-14.txt
>>> grep it for your FAS username and follow the dependency chain.
>>>
>>>  Package  (co)maintainers
>>> Status Change
>>> 
>>> patrikopravil: jruby pbrobinson: GConf2, jruby
>> Why am I listed against jruby?
> you should search for your name in the full report
>
> jruby blocks rubygem-json


Which is questionable on itself. I am quite sure that rubygem-json will
be fine without jruby, because the dependency will be satisfied by ruby.


Vít


>  and 
>
>   xapian-bindings (maintained by: denisarnaud, drago01,
> pbrobinson) xapian-bindings-1.4.14-3.fc33.src requires rubygem-json =
> 2.3.0-201.fc32
>
>
>   Dan
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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