Re: Thoughts welcome: interface between automated test gating and the "critical path"

2022-10-17 Thread Adam Williamson 
On Fri, 2022-09-02 at 10:26 -0700, Adam Williamson wrote:
> 
> > > If we don't think it's worth doing that work, then we're kinda stuck
> > > with openQA glomming onto the critpath definition to decide which
> > > updates to test and gate, because I don't have any other current viable
> > > choices for that, really. And we'd have to figure out a critpath
> > > definition that's as viable as possible for both purposes.
> > > 
> > > 
> > > BTW, one other thought I've had in relation to all this is that we
> > > could enhance the current critpath definition somewhat. Right now, it's
> > > built out of package groups in comps which are kinda topic-separated:
> > > there's a critpath-kde, a critpath-gnome, a critpath-server, and so on.
> > > But the generated critical path package list is a monolith: it doesn't
> > > distinguish between a package that's on the GNOME critpath and a
> > > package that's on the KDE critpath, you just get a big list of all
> > > critpath packages. It might be nice if we actually did distinguish
> > > between those - the critpath definition could keep track of which
> > > critpath topic(s) a package is included in, and Bodhi could display
> > > that information in the web UI and provide it via the API. That way
> > > manual testers could get a bit more info on why a package is critpath
> > > and what areas to test, and openQA could potentially target its test
> > > runs to conserve resources a bit, though this might require a bit more
> > > coding work on the gating stuff now I think about it.
> > 
> > That sounds useful. We only need a volunteer to figure out the details
> > and do the work ;)
> 
> I actually did a huge rewrite of the thing that generates the critpath
> data this week, and it probably wouldn't be to much work, honestly.
> The most annoying bit would be the Bodhi frontend stuff, but that's
> because I'm bad at frontend dev in general. :P But yeah, this is
> definitely off in sky-castle land. I'll add it to my ever-growing list
> of sky-castle projects to do when I get a couple of years of spare
> time...

So, an update on this whole area!

First off, I'm actually finding the time to do the sky-castle work. The
releng critpath script now outputs critpath data by group:
https://pagure.io/releng/c/621caa542acc142d57f1247e7644846f737f8eee?branch=main

Bodhi (git HEAD Bodhi, anyway) can now read data in that format:
https://github.com/fedora-infra/bodhi/pull/4755

and when this PR is merged, it will be able to mark updates as critpath
by groups:
https://github.com/fedora-infra/bodhi/pull/4759

This has the handy bonus effect of enabling us to remove one of our
remaining uses of PDC. Once the Bodhi work is merged, I can send a PR
for the releng ansible repo to define per-group greenwave policies, run
the critpath.py script nightly on the Bodhi boxes, and switch to the
'json' critpath type in Bodhi config, and finally I can then enhance
the openQA scheduler to only run the necessary tests for each update.

Second, since nobody really opposed the idea of extending the critpath
definition slightly, here's a formal proposal to implement that. I want
to edit the wiki critpath page:
https://fedoraproject.org/wiki/Critical_path_package

and change it as follows:

1. Under Background, change "The packages required to sustain these
actions make up the critical path." to:

"The packages required to sustain these actions initially made up the
critical path. Later, it was agreed that the maintainers of Editions,
spins, and labs can also declare packages that provide other key
functionality to be part of the ''critical path'' for that Edition,
spin or lab."

2. Under Actions, change the first two sentences to read:

"Packages required to perform the most fundamental actions on a system
are always considered part of the ''critical path''. Those actions
include: "

Does anyone object to these proposed changes? Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: The performance impact of various debug options on Fedora Rawhide debug kernels

2022-10-17 Thread Adam Williamson 
On Fri, 2022-10-14 at 10:27 -0500, Justin Forbes wrote:
> 
> Just to reiterate this is not being dropped. I did a bit of research,
> CONFIG_DEBUG_WW_MUTEX_SLOWPATH was actually turned back on in 2018, as
> upstream changed PROVE_LOCKING to select it. As such, there is no way
> to turn it off without turning off PROVE_LOCKING.   All things
> considered, PROVE_LOCKING has found a good number of bugs over the
> years. From the numbers you have given, there doesn't seem to be a
> whole lot of opportunity for real improvement without turning off that
> chain.  Overall, this requires some thought on the rawhide debug
> strategy more than anything else.   We do have things (CKI and
> similar) which can give us more useful data without making a debug
> kernel default, but it still doesn't catch issues seen in hardware
> drivers so much. Though if debug kernels have gotten slow enough that
> no one is running them anymore, opting for the no-debug repo, we may
> be better served by changing our strategy here.

My personal experience when running Rawhide on my main laptops is that,
yeah, debug kernels are sufficiently slow that I will stick to booting
one of the periodic non-debug builds unless I'm specifically running
into a kernel bug and want to see if the debug kernel provides more
information on it.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

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

Re: Confused by packager dashboard: FTBFS (source)

2022-10-17 Thread Richard Shaw 
On Mon, Oct 17, 2022 at 2:53 PM Fabio Valentini 
wrote:

> On Sat, Sep 24, 2022 at 1:55 PM Richard Shaw  wrote:
> >
> > On Sat, Sep 24, 2022 at 4:58 AM Fabio Valentini 
> wrote:
> >>
> >> Sat, Sep 24, 2022 at 8:39 AM Iñaki Ucar 
> wrote:
> >> >
> >> > I opened an issue in the dashboard repo for the same reason some
> weeks ago. It turns out there's a limitation on detecting these cases, so
> Fabio maintains a whitelist.
> >>
> >> I can add python-pyside2 to the list, if you give me the exact error
> you see.
> >> There are already a few packages that are filtered out because of
> >> qt5-qtwebengine, so you're in good company:
> >>
> https://pagure.io/ironthree/repochecker/blob/master/f/overrides.json#_106
> >
> >
> > The exact BR is:
> > cmake(Qt5WebEngine) >= 5.14
>
> Sorry for taking so long to get back to this. I only just managed to
> get my overflowing email inbox under control ...
> Either way, the python-pyside2 issue should be resolved now, and it
> appears the updated data has already propagated to the packager
> dashboard.
>

Thanks for following up!

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

Re: Confused by packager dashboard: FTBFS (source)

2022-10-17 Thread Fabio Valentini 
On Sat, Sep 24, 2022 at 1:55 PM Richard Shaw  wrote:
>
> On Sat, Sep 24, 2022 at 4:58 AM Fabio Valentini  wrote:
>>
>> Sat, Sep 24, 2022 at 8:39 AM Iñaki Ucar  wrote:
>> >
>> > I opened an issue in the dashboard repo for the same reason some weeks 
>> > ago. It turns out there's a limitation on detecting these cases, so Fabio 
>> > maintains a whitelist.
>>
>> I can add python-pyside2 to the list, if you give me the exact error you see.
>> There are already a few packages that are filtered out because of
>> qt5-qtwebengine, so you're in good company:
>> https://pagure.io/ironthree/repochecker/blob/master/f/overrides.json#_106
>
>
> The exact BR is:
> cmake(Qt5WebEngine) >= 5.14

Sorry for taking so long to get back to this. I only just managed to
get my overflowing email inbox under control ...
Either way, the python-pyside2 issue should be resolved now, and it
appears the updated data has already propagated to the packager
dashboard.

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

[Bug 2135468] CVE-2022-3517 perl-Code-TidyAll: nodejs-minimatch: ReDoS via the braceExpand function [fedora-all]

2022-10-17 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2135468

Guilherme de Almeida Suckevicz  changed:

   What|Removed |Added

 Blocks||2134609
   ||(CVE-2022-3517,PRISMA-2022-
   ||0039)





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2134609
[Bug 2134609] CVE-2022-3517 nodejs-minimatch: ReDoS via the braceExpand
function
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2135468
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2135468] CVE-2022-3517 perl-Code-TidyAll: nodejs-minimatch: ReDoS via the braceExpand function [fedora-all]

2022-10-17 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2135468



--- Comment #1 from Guilherme de Almeida Suckevicz  ---
Use the following template to for the 'fedpkg update' request to submit an
update for this issue as it contains the top-level parent bug(s) as well as
this tracking bug.  This will ensure that all associated bugs get updated
when new packages are pushed to stable.

=

# bugfix, security, enhancement, newpackage (required)
type=security

# low, medium, high, urgent (required)
severity=medium

# testing, stable
request=testing

# Bug numbers: 1234,9876
bugs=2134609,2135468

# Description of your update
notes=Security fix for [PUT CVEs HERE]

# Enable request automation based on the stable/unstable karma thresholds
autokarma=True
stable_karma=3
unstable_karma=-3

# Automatically close bugs when this marked as stable
close_bugs=True

# Suggest that users restart after update
suggest_reboot=False

==

Additionally, you may opt to use the bodhi web interface to submit updates:

https://bodhi.fedoraproject.org/updates/new


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2135468
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2135468] New: CVE-2022-3517 perl-Code-TidyAll: nodejs-minimatch: ReDoS via the braceExpand function [fedora-all]

2022-10-17 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2135468

Bug ID: 2135468
   Summary: CVE-2022-3517 perl-Code-TidyAll: nodejs-minimatch:
ReDoS via the braceExpand function [fedora-all]
   Product: Fedora
   Version: 36
Status: NEW
 Component: perl-Code-TidyAll
  Keywords: Security, SecurityTracking
  Severity: medium
  Priority: medium
  Assignee: jples...@redhat.com
  Reporter: gsuck...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora




More information about this security flaw is available in the following bug:

http://bugzilla.redhat.com/show_bug.cgi?id=2134609

Disclaimer: Community trackers are created by Red Hat Product Security team on
a best effort basis. Package maintainers are required to ascertain if the flaw
indeed affects their package, before starting the update process.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2135468
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Review swap for python-plotnine and dependencies

2022-10-17 Thread Sandro 

On 17-10-2022 18:36, Miro Hrončok wrote:

On 17. 10. 22 15:15, Sandro wrote:

Hi,

I have submitted reviews for python-plotnine and its dependencies:

python-plotnine
    python-scikit-misc
    python-adjustText
    pythn-mizani
    python-palettable



Could you please share the links?


Sure.

https://bugzilla.redhat.com/show_bug.cgi?id=2133439
https://bugzilla.redhat.com/show_bug.cgi?id=2133438
https://bugzilla.redhat.com/show_bug.cgi?id=2130030 (done)
https://bugzilla.redhat.com/show_bug.cgi?id=2130026
https://bugzilla.redhat.com/show_bug.cgi?id=2130025 (done)

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

Re: Review swap for python-plotnine and dependencies

2022-10-17 Thread Miro Hrončok 

On 17. 10. 22 15:15, Sandro wrote:

Hi,

I have submitted reviews for python-plotnine and its dependencies:

python-plotnine
   python-scikit-misc
   python-adjustText
   pythn-mizani
   python-palettable



Could you please share the links?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Current test branch: Error message systemd-gpt-auto-generator[1169]: Failed to dissect: Permission denied

2022-10-17 Thread Peter Boy 


> Am 17.10.2022 um 10:44 schrieb Zdenek Pytela :
> 
> 
> 
> On Sat, Oct 15, 2022 at 6:03 PM Peter Boy  wrote:
> With branch 20221012 as well as 20221014 I get with Fedora Server on BIOS 
> boot Hardware several AVC events like
> 
> type=AVC msg=audit(1665848517.93:288): avc: denied { sys_admin } for pid=1635 
> comm="systemd-gpt-aut" capability=21 
> scontext=system_u:system_r:systemd_gpt_generator_t:s0 
> tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability 
> permissive=0
> 
> I can’t find any impairments from it so far. 
> 
> ….
> Hello Peter,
> 
> I believe this AVC is harmless, refer to a systemd bz for more details:
> https://bugzilla.redhat.com/show_bug.cgi?id=2083900
> 
> and related kernel one:
> https://bugzilla.redhat.com/show_bug.cgi?id=2122888
> 

Hi Zdenek,

thanks for the info. I’ll add a corresponding note to our Fedora Server 
Documentation (unfortunately, when installing ServerVM via the console, it is 
very visible and could irritate a user).  


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)


Fedora Server Edition Working Group member
Fedora docs team contributor
Java developer and enthusiast


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

[Bug 2086256] perl-TAP-Formatter-JUnit-0.16 is available

2022-10-17 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2086256

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Assignee|berra...@redhat.com |jples...@redhat.com
 Resolution|--- |RAWHIDE
 CC||jples...@redhat.com
   Doc Type|--- |If docs needed, set a value
   Fixed In Version||perl-TAP-Formatter-JUnit-0.
   ||16-1.fc38
Last Closed||2022-10-17 13:58:49




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2086256
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2083132] Upgrade perl-Text-Template to 1.61

2022-10-17 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2083132

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Assignee|spo...@gmail.com|jples...@redhat.com
   Fixed In Version||perl-Text-Template-1.61-1.f
   ||c38
Version|37  |rawhide
 Resolution|--- |RAWHIDE
Last Closed||2022-10-17 13:26:23




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2083132
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Review swap for python-plotnine and dependencies

2022-10-17 Thread Sandro 

Hi,

I have submitted reviews for python-plotnine and its dependencies:

python-plotnine
  python-scikit-misc
  python-adjustText
  pythn-mizani
  python-palettable

Some have been sitting around waiting for a while now, so I thought I'd 
ask if somebody would be willing to swap reviews.


I'd be happy to do some reviews, preferably Python, in return.

Cheers,


--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fail2ban iptables issue: Fix with subpackage?

2022-10-17 Thread Richard Shaw 
On Mon, Oct 17, 2022 at 7:52 AM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Monday, 17 October 2022 at 14:34, Richard Shaw wrote:
> > This actually has to do with iptables vs nftables but I need to be able
> to
> > deal with it here.
> >
> > iptables wants the port ranges specified using a ":" as a separator but
> > nftables wants "-"...
> >
> > The problem is in the default jail.conf which is:
> >
> > # Ports to be banned
> > # Usually should be overridden in a particular jail
> > port = 0:65535
> >
> > My current thought is to create two sub-packages:
> > fail2ban-iptables
> > fail2ban-nftables
> >
> > I was thinking of using %post to do sed substitution for both packages
> (if
> > it's already correct it would end up being a no-op).
> >
> > Installing nftables by default since all current releases of Fedora use
> it
> > by default.
> >
> > Thoughts?
>
> Sounds good to me as a temporary solution. Have you discussed the move
> to nftables with upstream?
>

They initially made the change upstream but I guess ran into too many
issues with users still using iptables and reverted it. They have
subsequently given up and consider it a firewalld issue.

I think if I include jail.conf in both subpackages %post should work fine
(instead of %posttrans). It will be marked %config(noreplace) for updates
and if the packages are switched out, the sed substitution should work fine
or no-op.

I'll add the nftables package as "Recommends:" to the main package so it
will get installed by default and come up with some kind of virtual require
/ provides for both subpackages to make sure one is installed.

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

[Bug 2135378] New: perl-Future-0.49 is available

2022-10-17 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2135378

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



Releases retrieved: 0.49
Upstream release that is considered latest: 0.49
Current version/release in rawhide: 0.48-3.fc37
URL: http://search.cpan.org/dist/Future/

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://docs.fedoraproject.org/en-US/package-maintainers/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/11795/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Future


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2135378
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fail2ban iptables issue: Fix with subpackage?

2022-10-17 Thread Dominik 'Rathann' Mierzejewski 
On Monday, 17 October 2022 at 14:34, Richard Shaw wrote:
> This actually has to do with iptables vs nftables but I need to be able to
> deal with it here.
> 
> iptables wants the port ranges specified using a ":" as a separator but
> nftables wants "-"...
> 
> The problem is in the default jail.conf which is:
> 
> # Ports to be banned
> # Usually should be overridden in a particular jail
> port = 0:65535
> 
> My current thought is to create two sub-packages:
> fail2ban-iptables
> fail2ban-nftables
> 
> I was thinking of using %post to do sed substitution for both packages (if
> it's already correct it would end up being a no-op).
> 
> Installing nftables by default since all current releases of Fedora use it
> by default.
> 
> Thoughts?

Sounds good to me as a temporary solution. Have you discussed the move
to nftables with upstream?

Regards,
Dominik (who has migration to nft still on his TODO list)
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

License correction for libIDL-doc

2022-10-17 Thread Ben Beasley 
While converting libIDL to SPDX (LGPLv2+ → LGPL-2.0-or-later), I noticed 
that the documentation is actually GPLv3+. The libIDL-doc subpackage’s 
License field is therefore corrected from LGPLv2+ to GPL-3.0-or-later.


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

fail2ban iptables issue: Fix with subpackage?

2022-10-17 Thread Richard Shaw 
This actually has to do with iptables vs nftables but I need to be able to
deal with it here.

iptables wants the port ranges specified using a ":" as a separator but
nftables wants "-"...

The problem is in the default jail.conf which is:

# Ports to be banned
# Usually should be overridden in a particular jail
port = 0:65535

My current thought is to create two sub-packages:
fail2ban-iptables
fail2ban-nftables

I was thinking of using %post to do sed substitution for both packages (if
it's already correct it would end up being a no-op).

Installing nftables by default since all current releases of Fedora use it
by default.

Thoughts?

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

Fedora 37 compose report: 20221017.n.0 changes

2022-10-17 Thread Fedora Rawhide Report 
OLD: Fedora-37-20221016.n.0
NEW: Fedora-37-20221017.n.0

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

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

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

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

2022-10-17 Thread updates 
The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-473e5052db   
ckeditor-4.20.0-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-576e858e93   
php-Smarty-3.1.47-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-22e6871166   
drupal7-7.92-1.el7


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

python-vcstool-0.3.0-1.el7

Details about builds:



 python-vcstool-0.3.0-1.el7 (FEDORA-EPEL-2022-8b4d09cc07)
 Tool to invoke vcs commands on multiple repositories

Update Information:

Update to `vcstool` 0.3.0.  This update drops Python 2 support in EPEL 7.

ChangeLog:

* Sun Oct 16 2022 Scott K Logan  - 0.3.0-1
- Update to 0.3.0 (rhbz#1991775)
- Drop Python 2 subpackage, which is no longer supported upstream

References:

  [ 1 ] Bug #1991775 - python-vcstool-0.3.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1991775


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

Re: DNF5 Blockers

2022-10-17 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, Oct 12, 2022 at 05:21:58PM -0400, Paul Frields wrote:
> On Tue, Oct 11, 2022 at 7:13 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
> 
> > On Tue, Oct 11, 2022 at 11:48:14AM +0200, Fabio Valentini wrote:
> > > On Mon, Oct 10, 2022 at 9:15 AM Jaroslav Mracek 
> > wrote:
> > > >
> > > > Please can you be more specific which kind of functionality is
> > required for particular command? Why is it important to know what user case
> > you want to resolve it? Commands has multiple options and some of them
> > could be unused. Specially repoquery has tons of options. Knowing critical
> > usercase will help us a lot to not only provide the same option but to
> > improve DNF5 behavior in comparison to DNF4.
> > > >
> > > > I recommend to create for each user case or command an issue -
> > https://github.com/rpm-software-management/dnf5/issues. Please provide as
> > much as possible information to understand the user case to be able to set
> > a proper priority.
> > >
> > > Determining the scope of such big Changes is usually done by the
> > > person who proposes the change ...
> > > I think it's safe to assume that most commands / options are used by
> > > at least some people / tools / scripts, so dropping features is going
> > > to be painful, and should be avoided, if possible.
> >
> > Yes. And looking at this from the other angle: if you ask people what
> > features they need, the answer will be "yes" ;) Essentially, pretty
> > much every feature ever created has *some* user, and often people will
> > only remember about a feature when it turns out that it is missing in
> > the new implementation. Also, other things being equal, people prefer
> > that the interface is unchanged. This just makes life easier for them.
> >
> 
> I agree with you Zbyszek. OTOH "identical interface" doesn't seem like a
> fair requirement. (I don't believe you were suggesting it was.)

I wasn't. An identical interface (or part thereof) is in fact often
easiest for both sides, both people writing the interface and people
consuming the interface. But in various cases it's too hard to provide
an identical interface. Thus: try to provide an identical or at least
a backwards-compatible interface, but deviate if necessary.

> > Thus, if we're switching to an entirely new system where
> > reimplementing every feature and interface of the old system is not
> > possible, people proposing the change need to figure out what *can* be
> > implemented, and weigh the efforts required against how needed the
> > feature really is,
> 
> 
> This sounds reasonable -- describe what will be provided at a minimum.
> 
> 
> > propose alternatives for things which are too hard
> > or too costly to reimplement,
>
> This sounds reasonable if all we're asking is to provide suggestions or
> alternatives for a few things that are more prominent changes. Not
> alternatives for every possible function. That would divert too much energy
> from more useful work.

Well, maybe. I think some such answer will need to be provided for
pretty much every feature that people ask about. Maybe not at level
of all implementation details, but at the feature level certainly.

> > and in the end make some judgement calls.
> Are you suggesting the DNF team can make these calls? That sounds like a
> collegial level of trust and seems okay, if so. But it seems at odds with
> the original request, so it should be clear who's accountable for making
> what calls.

I think the DNF team should make those calls but then submit the
resulting plan for public discussion and vote by FESCo.

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

Re: F38 proposal: Deprecate python-toml (Self-Contained Change proposal)

2022-10-17 Thread Miro Hrončok 

On 15. 10. 22 19:23, Miro Hrončok wrote:

7. python-pep517


https://github.com/pypa/pep517/pull/150

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2022-10-17 Thread updates 
The following builds have been pushed to Fedora EPEL 8 updates-testing

python-osrf-pycommon-2.1.0-1.el8
python-vcstool-0.3.0-1.el8

Details about builds:



 python-osrf-pycommon-2.1.0-1.el8 (FEDORA-EPEL-2022-1ce0dca57f)
 Commonly needed Python modules used by software developed at OSRF

Update Information:

Update to `osrf_pycommon` 2.1.0.  Drop Python 2 subpackage in EPEL 8 lacking
upstream support.

ChangeLog:

* Sun Oct 16 2022 Scott K Logan  - 2.1.0-1
- Update to 2.1.0 (rhbz#2054780)
- Switch from nose to pytest
- Drop Python 2 from spec file as it isn't supported upstream anymore

References:

  [ 1 ] Bug #2054780 - python-osrf-pycommon-2.1.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2054780




 python-vcstool-0.3.0-1.el8 (FEDORA-EPEL-2022-f925a1fab8)
 Tool to invoke vcs commands on multiple repositories

Update Information:

Update to `vcstool` 0.3.0.  This update drops Python 2 support in EPEL 7.

ChangeLog:

* Sun Oct 16 2022 Scott K Logan  - 0.3.0-1
- Update to 0.3.0 (rhbz#1991775)
- Drop Python 2 subpackage, which is no longer supported upstream

References:

  [ 1 ] Bug #1991775 - python-vcstool-0.3.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1991775


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

Re: F38 proposal: Deprecate python-toml (Self-Contained Change proposal)

2022-10-17 Thread Miro Hrončok 

On 15. 10. 22 19:23, Miro Hrončok wrote:

8. python3-sphinx-theme-builder


https://github.com/pradyunsg/sphinx-theme-builder/pull/35

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Dual licenses question

2022-10-17 Thread Sandro 

On 17-10-2022 12:19, Artur Frenszek-Iwicki wrote:

Would that imply I have to add the LGPL license text to the package
myself?

The packaging guidelines state that the desired course of action is
to contact upstream and ask them to provide the licence text. 
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text


Thanks. I already opened an issue upstream [0]. Just wanted to be sure 
regarding dual licenses.


On 17-10-2022 12:24, Daniel P. Berrangé wrote:


If the COPYRIGHT file explicitly stated the PNG files are dual licensed,
then (in the absence of any more explicit statement elsewhere in the
source tree) the COPYRIGHT file statement is considered binding, despite
the fact they forgot to ship the actual LGPL license file text. Upstream
should be encouraged to ship the license text to make this more clear
though.


Thanks. Upstream is quite responsive. I will provide a patch to include 
the missing license text.


[0] https://github.com/Brewtarget/brewtarget/issues/664

-- 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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F38 proposal: Deprecate python-toml (Self-Contained Change proposal)

2022-10-17 Thread Miro Hrončok 

On 15. 10. 22 19:23, Miro Hrončok wrote:

8. python-pyproject-metadata


https://github.com/FFY00/python-pyproject-metadata/pull/32

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [side tags] Undesired automatic side-tag removal happened - how to deal with it in the future?

2022-10-17 Thread Zdenek Dohnal 
Koji devs forwarded me to releng pagure, so there is a new issue for 
this https://pagure.io/releng/issue/11093 .


On 10/14/22 12:57, Zdenek Dohnal wrote:

Hi Kevin,

I've created the issue https://pagure.io/koji/issue/3554 for the problem.

I agree with docs update (maybe it would be nice as well mention the 
side tag disappears once the packages are in stable, so users don't 
have to try removing it :) ) and the script update (adding 
--inactive-delay option, probably set to 21 days?)


Thank you for looking into it!


Zdenek


On 10/11/22 03:16, Kevin Fenzi wrote:


got automatically deleted, even when it had builds connected to it 
already. Documentation [1] does not mention any automatic 
side-tags cleanup and its deadlines.

We should update the docs. We did announce adding this.

Although packagers can create a new side tag easily, I found it 
inconvenient for maintainers, because the synchronization among 
the maintainers can take weeks to finish the rebuild and release 
the update and automatic removal without notice (do excuse me if I 
missed a notification email about this - I have many filters and 
it could end up somewhere where I wasn't able to find it) prolongs 
this process.


What I would like to propose are the following options:

A) don't do side-tag cleanups after a specific time frame, but 
only when the specific event happens - branching, GA, EOL - it can 
be consuming to our resources, but maintainer are still able to 
remove the side tags manually in case it contains a big set of 
packages and AFAIK the process itself is not such spread in usage...

Side tags are actually pretty costly on the server end. It means every
single time a build lands in the parent tag they have to have their
rpeodata regenerated. It's tons of newRepos. I'd prefer to clean them up
as quickly as we can, but no quicker. :)


or

B) do a side-tags cleanup and mention it in the documentation 
together with specification what the removal's time frame is, so 
maintainers can act accordingly

We should do this in any case.


or

C) (my preferred) Koji or releng (depends on whether the cleanup 
happened automatically or manually) will send an email to a side 
tag creator with 'Hi, your side tag is going to expire - do you 
need it?' Or with automaton - 'use this command to prolong it.' 
And if there is no response or if the creator approves, remove the 
side tag.

Doable, but more notifications and things to deal with.

Note that sidetag cleanup has a newer option we aren't using yet too:

   --inactive-delay=DAYS
 delete tags inactive for DAYS (no build was 
un/tagged

 there)

We could perhaps use this.

IMO basically side-tag is not expected to exist for such a long 
time, side-tag requester should
take effort to merge it into main buildroot within, say, one week 
at most.

I'm not sure this is always going to be realistic. We are increasingly
encouraging folks to do big complicated rebases in side tags rather
than breaking Rawhide or Branched for days at a time; sometimes this
might take more than a week. I don't want folks to be discouraged from
using side tags and just go back to breaking Rawhide because of this
kind of cleanup.

I agree... I'm open to adjusting the cleanup script, but I do think we
should limit sidetags somewhat.

We should in any case document and fix the empty thing.

kevin

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

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue



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

Re: Dual licenses question

2022-10-17 Thread Daniel P . Berrangé 
On Mon, Oct 17, 2022 at 12:10:26PM +0200, Sandro wrote:
> Hi,
> 
> I'm currently updating brewtarget [0] which I recently adopted.
> 
> For a handful of PNG files upstream has the following in their COPYRIGHT
> file: License: CC-BY-SA-3.0 or LGPL-3.0 [1].
> 
> The text of the CC license is in the file, however the text of the LGPL
> license is not, nor is it shipped separately. Does upstream need to ship the
> text of the LGPL license or does it imply the PNG files are shipped under
> the CC license?

If the COPYRIGHT file explicitly stated the PNG files are dual licensed,
then (in the absence of any more explicit statement elsewhere in the
source tree) the COPYRIGHT file statement is considered binding, despite
the fact they forgot to ship the actual LGPL license file text. Upstream
should be encouraged to ship the license text to make this more clear
though.

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

Re: Dual licenses question

2022-10-17 Thread Artur Frenszek-Iwicki 
> Would that imply I have to add the LGPL license text to the package myself?
The packaging guidelines state that the desired course of action
is to contact upstream and ask them to provide the licence text.
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text

For what it's worth, the typical licence header for LGPL includes this bit:
> You should have received a copy of the GNU Lesser General Public License
> along with this program. If not, see .
So personally, I'd start by submitting an issue upstream and asking for 
clarification.

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

Re: DNF5 Blockers

2022-10-17 Thread Jaroslav Mracek 
I agree.

The thread was created by community to ask community what should be the minimal 
scope to approve the change proposal. As a DNF team lead I would be very happy 
to get any input from community, because it will help us to prioritize tasks.

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

Dual licenses question

2022-10-17 Thread Sandro 

Hi,

I'm currently updating brewtarget [0] which I recently adopted.

For a handful of PNG files upstream has the following in their COPYRIGHT 
file: License: CC-BY-SA-3.0 or LGPL-3.0 [1].


The text of the CC license is in the file, however the text of the LGPL 
license is not, nor is it shipped separately. Does upstream need to ship 
the text of the LGPL license or does it imply the PNG files are shipped 
under the CC license?


In the specfile I put 'CC-BY-SA-3.0 OR LGPL-3.0-only' to cover both. 
Would that imply I have to add the LGPL license text to the package myself?


[0] https://copr.fedorainfracloud.org/coprs/gui1ty/reviews/build/4948105/
[1] 
https://github.com/Brewtarget/brewtarget/blob/42359a23715a6275aeca2fb27456715a1c7758c3/COPYRIGHT#L28


Cheers,
--
Sandro
FAS: gui1ty
IRC: Penguinpee
Elsewhere: [Pp]enguinpee
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2133212] perl-Hash-Merge-Simple can not be installed on Rocky Linux 8

2022-10-17 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2133212

Paul Howarth  changed:

   What|Removed |Added

 Resolution|--- |NOTABUG
Summary|perl-hash-Merge-Simple can  |perl-Hash-Merge-Simple can
   |not be installed on Rocky   |not be installed on Rocky
   |Linux 8 |Linux 8
 Status|NEW |CLOSED
Last Closed||2022-10-17 09:13:25




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2133212
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RPM Sequoia - respect system's crypt policy

2022-10-17 Thread Neal H. Walfield 
On Thu, 13 Oct 2022 09:29:27 +0200,
Panu Matilainen wrote:
> >> - Some old, insecure (MD5/SHA1 based) signatures are rejected (this is
> >> in line with the stronger crypto settings proposed elsewhere for F38)
> > 
> > Such a hardcoded restriction, without a way for the local administrator to
> > allow the legacy signatures, is not acceptable.
> 
> Mind you, I don't exactly agree with this style of explicit disabling
> either (see
> https://lists.rpm.org/pipermail/rpm-maint/2021-October/018344.html and
> onwards). But. I doubt many people realize just how thin the ice is
> (and has always been) with the existing parser. I consider this step a
> matter of survival, and ultimately some legacy content becoming harder
> to use is an acceptable tradeoff for *that*.
> 
> I don't know how deep this all is wired inside Sequoia, but I totally
> agree (as you see in the thread linked above) that this should be
> based on the system crypto policy. As explained in the change, nettle
> (which doesn't support the system crypto policies AIUI) should be seen
> as a temporary stepstone in Fedora, with a plan to switch to openssl
> (which does) in the nearish future.
> 
> So technically this is a matter of "Sequoia should honor system crypto
> policy", rpm is just a dumb API user here that sometimes get told
> "nope" by the underlying libraries, whether due to crypto policy, FIPS
> or whatever.

I opened [1] to track this issue.

It should be relatively straightforward to implement this.  Sequoia
already has first class policy objects that are consulted on every
cryptograph operation [2].  What needs to be done is to read the
Fedora system policy and configure the rpm-sequoia's policy object [3]
appropriately.

:) Neal

[1] https://github.com/rpm-software-management/rpm-sequoia/issues/14
[2] https://docs.sequoia-pgp.org/sequoia_openpgp/policy/index.html

https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html
[3] 
https://github.com/rpm-software-management/rpm-sequoia/blob/main/src/lib.rs#L121
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Current test branch: Error message systemd-gpt-auto-generator[1169]: Failed to dissect: Permission denied

2022-10-17 Thread Zdenek Pytela 
On Sat, Oct 15, 2022 at 6:03 PM Peter Boy  wrote:

> With branch 20221012 as well as 20221014 I get with Fedora Server on BIOS
> boot Hardware several AVC events like
>
> type=AVC msg=audit(1665848517.93:288): avc: denied { sys_admin } for
> pid=1635 comm="systemd-gpt-aut" capability=21
> scontext=system_u:system_r:systemd_gpt_generator_t:s0
> tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability
> permissive=0
>
> I can’t find any impairments from it so far.
>
> I couldn’t find anything about it besides an old bug report:
> https://bugzilla.redhat.com/show_bug.cgi?id=1499479
>
>
> Does anyone have information on whether this can be safely ignored?
>
>
>
> Some Details:
>
> Deploying the ServerKVM immediately after completing the first boot
> configuration I get 2 times the message
>
> systemd-gpt-auto-generator[1169]: Failed to dissect: Permission denied
>
> The system proceeds with any problem and finally shows the login prompt.
>
> Accordingly I find in audit.log:
>
> type=AVC msg=audit(1665836956.540:288): avc: denied { sys_admin } for
> pid=1249 comm="systemd-gpt-aut" capability=21
> scontext=system_u:system_r:systemd_gpt_generator_t:s0
> tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability
> permissive=0
>
>
> The same happens with a standard installation of Fedora Server on
> hardware. The system boots to login without issues. But as soon as I
> perform a file operation, e.g. creating log. volume and a filesystem I get
> the same AVC event.
>
> type=AVC msg=audit(1665848517.93:288): avc: denied { sys_admin } for
> pid=1635 comm="systemd-gpt-aut" capability=21
> scontext=system_u:system_r:systemd_gpt_generator_t:s0
> tcontext=system_u:system_r:systemd_gpt_generator_t:s0 tclass=capability
> permissive=0
>
Hello Peter,

I believe this AVC is harmless, refer to a systemd bz for more details:
https://bugzilla.redhat.com/show_bug.cgi?id=2083900

and related kernel one:
https://bugzilla.redhat.com/show_bug.cgi?id=2122888


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


-- 

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

Re: Current F37 test branch: probably new SELinux AVCs with libvirt / KVM

2022-10-17 Thread Zdenek Pytela 
On Sat, Oct 15, 2022 at 6:55 PM Peter Boy  wrote:

> When creating a new VM on Fedora Server I get 2 AVCs, which I didn’t
> noticed in F36:
>
> SELinux is preventing virtlogd from using the execmem access on a process.
> type=AVC msg=audit(1665815361.392:451): avc: denied { execmem } for
> pid=2086 comm="virtlogd"
> scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tclass=process
> permissive=0
>
>
> SELinux is preventing libvirt_leasesh from using the execmem access on a
> process.
> type=AVC msg=audit(1665851006.673:774): avc: denied { execmem } for
> pid=6252 comm="libvirt_leasesh"
> scontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 tclass=process
> permissive=0
>
>
> These execmem access violations were virulent a few years ago, but at
> least on my F36 servers I haven't seen any of them anymore.
>
> Am I the only one where they are back?
>
Hello Peter,

There is a bugzilla:

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

which is being worked on.

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


-- 

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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-17 Thread Jaroslav Mracek 
I believe that problems related to usage of DNF and DNF5 in parallel are 
ecplained in following section - 
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Problems_related_to_using_DNF5_and_DNF_in_parallel_for_software_modification

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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-17 Thread Jaroslav Mracek 
> So, coming back to the steps needed for this to happen as discussed in the 
> FESCo ticket, I
> think the first one is to decide how users can start testing dnf5 on
> "expendable" machines.
> 
> The proposal says that dnf5 can be installed in parallel with dnf. I think 
> this
> doesn't highlight what things will be broken, as tools will still use dnf. 
> Also,
> @zbysek asked in the FESCo ticket what data from the RPM database is shared 
> between the
> two, but didn't receive a reply: say, as a user, I install dnf5 in parallel 
> with dnf,
> will I be able to "dnf install foo" and then "dnf5 uninstall foo"?

Thank you for pointing it out. I will provide additional information in both 
Fedora proposals (replacement of DNF 
https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Scope and microdnf 
https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf#Scope). Using DNF 
and DNF5 in parallel to manage your system is safe. Both packagers will see 
content modification correctly, but they will not have not additional 
information to performed transaction. The situation will be the sile like when 
you do operation using RPM directly.

> 
> For those two things I wrote above, if in the end dnf5 will be renamed back 
> as dnf to be a
> drop in replacement, wouldn't be better to have dnf5 obsolete dnf starting 
> from now? I
> don't think anyone is going to test it on a production machine anyway...
> 
> Mattia

There is no plan to rename DNF5 to DNF. Our team already shipped YUM as DNF and 
we discovered that it is not good idea. DNF5 upstream is not going to repeat 
the same mistake.

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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-17 Thread Jaroslav Mracek 
> Il 12/10/22 12:28, Vít Ondruch ha scritto:
> My guess is that dnf5 is an entirely different beast than dnf. dnf was
> written in python, dnf5 is written in C (?), so it's not just a major
> version upgrade.
> 
> Mattia

It is correct, DNF5 is a different product written in C++.

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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-17 Thread Sandro 

On 17-10-2022 09:28, Jaroslav Mracek wrote:

* Naming unification of DNF5 stack - it will be quite strange to name
something dnf that cannot provide dnf and so on.


So RUM it is then: Re-invented Update Manager.

Re-invented like the wheel and should suit all consuming parties. :)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-17 Thread Vít Ondruch 


Dne 17. 10. 22 v 9:28 Jaroslav Mracek napsal(a):

Thank you for pointing this. Why DNF5 is not named as DNF and why we do not 
plan to name it as DNF?
DNF5 is a completely new product. It replaces dnf and microdnf. DNF5 doe's the 
same type of work like dnf, microdnf but behavior, internals, and plugins 
differents. If we will name DNF as DNF5 we will create a confusion for users. 
From our point of view it is much better to say that DNF5 is a new product with 
compatibility to DNF than it is enhanced DNF.
It is quite the same what happened with replacement of yum by DNF. In some 
distribution DNF was shipped as YUM in version 4 and it created a lot of 
confusions.



So why there is proposed the `/usr/bin/dnf` symlink? To create the 
confusion again?




On the other side we want to use DNF trademark, because it inherits a lot but 
still DNF5 is not the same as DNF.
With the naming of out stack we have a lot of restriction and I will try to 
mention some of them:
  * DNF5 cannot be named as DNF because there is requirement of parallel 
installability in Fedora 38.



This ^^ is self-imposed restriction. From practical POV, if DNF5 works 
and provides all required functionality, there is no need for parallel 
installability.




  * Python import of DNF5 cannot be shipped as DNF because we need to support 
parallel installability of Python bindings of DNF and DNF5 (same for libdnf and 
libdnf5 python pindings).
  * Naming unification of DNF5 stack - it will be quite strange to name 
something dnf that cannot provide dnf and so on.



I am not convinced. Your store is not consistent. On one hand, you want 
to provide as much compatibility as possible, but on the other hand, you 
does not hesitate to break the first think you can and that is the name.


Honestly, if DNF is written in Python or C++ and if there are libraries 
or bindings or what not is just implementation detail. I understand it 
matters to you, as a developer. I understand it matters to several other 
people maintaining some DNF plugins. But it does not matter and should 
not really matter to end user.


IOW if we need to update the documentation for DNF in a way that `dnf 
install --some-option something` does not work DNF5 and `dnf install 
--new-option something` must be used, that is fine. But if the change 
was to `dnf5 install --some-option something`, because "we keep the 
compatibility, the options are the same of course", then this would be 
ridiculous. Yes, I know "the symlink". But you want to avoid confusion 
as you said, then why the symlink which will create just confusion.



Vít





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


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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-17 Thread Jaroslav Mracek 
I am sorry, DNF and DNF5 is not a Fedora packager. DNF and DNF5 is an upstream 
project shipped to Fedora and other distributions including OpenSuse.

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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-17 Thread Jaroslav Mracek 
Thank you for pointing this. Why DNF5 is not named as DNF and why we do not 
plan to name it as DNF?
DNF5 is a completely new product. It replaces dnf and microdnf. DNF5 doe's the 
same type of work like dnf, microdnf but behavior, internals, and plugins 
differents. If we will name DNF as DNF5 we will create a confusion for users. 
From our point of view it is much better to say that DNF5 is a new product with 
compatibility to DNF than it is enhanced DNF.
It is quite the same what happened with replacement of yum by DNF. In some 
distribution DNF was shipped as YUM in version 4 and it created a lot of 
confusions.
On the other side we want to use DNF trademark, because it inherits a lot but 
still DNF5 is not the same as DNF.
With the naming of out stack we have a lot of restriction and I will try to 
mention some of them:
 * DNF5 cannot be named as DNF because there is requirement of parallel 
installability in Fedora 38.
 * Python import of DNF5 cannot be shipped as DNF because we need to support 
parallel installability of Python bindings of DNF and DNF5 (same for libdnf and 
libdnf5 python pindings).
 * Naming unification of DNF5 stack - it will be quite strange to name 
something dnf that cannot provide dnf and so on.

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

Re: F39 proposal: Replace DNF with DNF5 (System-Wide Change proposal)

2022-10-17 Thread Jaroslav Mracek 
> Sorry for the delay in my reply here. ;( 
> 
> Some questions: 
> 
> 
> no releng ticket? :( 
> 
> releng depends on dnf4 for a LOT of scripts. 
> We will need a lot of help moving those to dnf5 I am sure. 
> A porting guide for the python bindings would be welcome.

In source (header files) we have replace tags that are supposed to help with 
porting.
// @replaces dnf:dnf/base.py:method:Base().install(self, pkg_spec, 
reponame=None, strict=True, forms=None)

Additionally we have a plan to provide Python tutorial to make porting easy. 
Right now, documentation is our priority.


> 
> 
> A document like the yum2dnf man page with every single change would be
> welcome. Also it would be nice if dnf5 accepted things and just warned
> on them... ie '--refresh' or 'list' (use repoquery I guess)...

Good suggestion and we plan to provide such a document

> 
> 
> I see a big one missing: koji
> 
> We also have some applications that might use dnf python bindings
> (bodhi, packages, etc)
> 
> IMHO, I think it would be nice to get dnf5 reviewed and landed in Fedora
> as soon as you can, because then you would have a place for people to
> file bugs and iterate on things, but of course thats up to you.

The package review process for DNF5 is close to finish, therefore we expect 
release soon.

> 
> kevin

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