[Bug 1808799] perl-Dist-Zilla-6.014 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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



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

Fedora-Cloud-30-20200303.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: Ideas and proposal for removing changelog and release fields from spec file

[clime]

On Tue, 3 Mar 2020 at 00:28, clime  wrote:
>
> Ad. Zbyszek:
>
> > What about doing --.?
> > This means that upgrade path not affected by the number of commits or
> > builds in the older release.
>
> I was thinking how to properly implement this into rpkg-util and then
> finally, it clicked for me.
>
> First, I added the prefix parameter for git_release macro (below
> git_dir_release is used instead, which is the recommended form). Hence
> now, one can specify:
>
> Release: {{{ git_dir_release prefix="0%{?dist}" }}}
>
> which would produce release strings like:
>
> 0.fc32.1
> 0.fc32.2
> 0.fc32.3

Actually, that wouldn't work because prefix needs to be static, not
dependent on rpm macros (we would be searching for tags that contain
literally '0%{?dist}' in the last release part after the dash when
generating the current release based on past tag names). Only the
below versions that depend just on Git would work. I was hoping I can
get a fallback for cases like Nicolas or the ruby packages have but
that doesn't seem to be possible (at least to me at the moment).

>
> for each tag in f32 branch. The leading zero is not used here for
> anything but without it, we would get NVRs like somepkg-1.0-.fc32.1 -
> i.e. dash would be followed by immediate dot, which is not actually
> invalid but it is strange.
>
> Then it came to me that instead of %{dist} we can simply use branch
> name and hence (finally) drop "c" from .fcXY:
>
> Release: {{{ git_dir_release prefix="$GIT_BRANCH" }}}
>
> ("$GIT_BRANCH" is a macro variable that gives you name of the
> currently checked out branch)
>
> This will not work for cases when people put some special stuff into
> %{dist} like Nicolas showed:
> https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/fedora-release.spec#_488
> but it would work for simple cases and fallback would be possible.

See above, regrettably.

>
> Finally, one can just alias `git_dir_release prefix="$GIT_BRANCH"`
> with `git_dir_release_branched`
> (https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/git.bash#_464)
> and hence get the following:
>
> Release: {{{ git_dir_release_branched }}}
>
> which will be bumping release with respect to the latest tag on the
> current branch as well as the commits stacked on top of that tag (it
> will be also bumping release for uncommitted work if your working tree
> is dirty but i don't want to show it here now because NVRs are then
> quite long).
>
> I've prepared a test project for this new macro:
> https://pagure.io/hello_rpkg_release. You need the latest "rpkg" and
> "rpkg-macros" from
> https://copr.fedorainfracloud.org/coprs/clime/rpkg-util/ for it to
> work. But I also just dumped the results here:
> https://pagure.io/hello_rpkg_release/tree/result . You can see what
> NVRs are generated (by `rpkg nvr` command) at each particular point
> for the given branch (i.e. hello_rpkg_release-1.14.0-f32.2 for the
> second tagged commit in f32 branch) -- they are written down after the
> "-->" arrow. I mention there three NVRs in total:
>
> hello_rpkg_release-1.14.0-master.1  (the first tagged commit master branch
> hello_rpkg_release-1.14.0-f32.2  (the second tagged commit in the f32 branch)
> hello_rpkg_release-1.14.0-f31.1.git.1.34684da9  (untagged commit on
> top of the first tagged commit in the f31 branch)
>
> Any feedback welcome.
>
> On Mon, 2 Mar 2020 at 14:51, Neal Gompa  wrote:
> >
> > On Mon, Mar 2, 2020 at 8:46 AM clime  wrote:
> > >
> > > On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
> > >  wrote:
> > > >
> > > > If you don’t keep things decentralized you’ll be in a word of pain when
> > > > the scm or buildsys needs to be changed for another implementation (not
> > > > to mention, that’s not a good way to collaborate with other distros).
> > > > That will happen eventually. Web apps are not eternal.
> > >
> > > Full decentralization likely means that everyone has its own git repo
> > > and we can only sync by mailing list. I think src.fp.o is a good point
> > > where things can be done and where we can agree on what the packages
> > > that Fedora produce are (meaning we need a canonical source of package
> > > sources, otherwise it would be more complex to put a distribution
> > > together).
> > >
> >
> > This is not true. Pagure accepts PRs from arbitrary Git servers just
> > fine via the remote PR feature, so we do support decentralized
> > workflows without resorting to sending patches via email or Bugzilla.
> >
> >
> >
> > --
> > 真実はいつも一つ！/ 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

[389-devel] 389 DS nightly 2020-03-03 - 96% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2020/03/03/report-389-ds-base-1.4.3.3-20200303gitc013a02.fc31.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Non-responsive maintainer: pocock

[Neal Gompa]

On Fri, Feb 28, 2020 at 1:23 PM Julian Sikorski  wrote:
>
> Hi Daniel,
>
> I would like to add to Ankur's point: while I understand that many of us are 
> doing Fedora work voluntarily and the expectations should be set accordingly, 
> I believe we should be open to accept help when we realise that we cannot 
> realistically commit enough time to the project. In case of asio, I have 
> contacted you back in 2018 [1][2]. The pull request I have filed [3] has been 
> opened since.
> The situation with asio right now is that Fedora with its asio-1.10.8 is not 
> only behind arch and gentoo (both at 1.14.0), but also behind debian buster 
> (at 1.12.2). Resiprocate, which is what was holding back asio update, has 
> been retired due to FTBFS, then unorphaned at your request, and then retired 
> again after being orphaned for 6+ weeks [4]. There has not been a successful 
> build of resiprocate since 2016 [5].
> Again, I perfectly understand that you have a backlog and that updating asio 
> is not on top on your priority list. Being sceptical about co-maintainership 
> offers seems counter-productive though, as there are things which need fixing 
> and other people willing to step in.
>

Hello Daniel,

I would like to suggest that given our community and its modus
operandi, I think it would be unfair to automatically be suspicious of
the work fellow packagers are trying to do to help you. But, if it
helps, I'd be willing to assist with the asio package. Hopefully, my
track record speaks for itself, in terms of maintaining packages in
Fedora and contributing to various aspects of the Project. I also
sponsored Dakota (the OP who asked you about asio), and I have been
mentoring him on how to interact with the larger Fedora community and
I was the one who encouraged him to reach out to you on asio for EPEL
8.

If you feel you are no longer able to give it the attention it needs,
I would respectfully request you transfer the ownership to Dakota, who
is interested in maintaining the package. If you have some concern
with him maintaining it, feel free to transfer the package to me
instead. Failing that, please just orphan the package so someone can
take care of it in your stead.

Thanks in advance, and thank you for being a member of the Fedora community.

Best regards,
Neal


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

[389-devel] Re: Thoughts on swapping to rfc2307bis.ldif by default

[William Brown]

> On 3 Mar 2020, at 11:18, William Brown  wrote:
> 
> 
> 
>> On 3 Mar 2020, at 04:32, thierry bordaz  wrote:
>> 
>> 
>> 
>> On 3/2/20 7:24 AM, William Brown wrote:
>>> Hi all,
>>> 
>>> As you may know, I'm currently working on a migration utility to help move 
>>> from other ldap servers to 389-ds. Something that I have noticed in this 
>>> process is that other servers default to rfc2307bis.ldif [0] by default. As 
>>> part of the migration I would like to handle this situation a bit better. 
>>> It's likely not viable for me to simply plaster rfc2307bis into 99user.ldif 
>>> as part of the migration process, so I want to approach this better.
>>> 
>>> rfc2307 and rfc2307bis are incompatible schemas that redefine the same OIDs 
>>> with new/different meanings. Some key examples:
>>> 
>>> * posixGroup in rfc2307 only requires gidNumber, rfc2307bis requires cn and 
>>> gidNumber.
>> Is not it the opposite ?
> 
> I was reading the schema as I was reading this.

I need to apologise for being so short in this answer! Thierry was correct in 
this case.

Here is the full set of differences between the two:

uidNumber: +EQUALITY integerMatch
gidNumber: +EQUALITY integerMatch
gecos: +EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.26 -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
homeDirectory: +EQUALITY caseExactIA5Match
loginShell: +EQUALITY caseExactIA5Match
shadowLastChange: +EQUALITY integerMatch
shadowMin: +EQUALITY integerMatch
shadowMax: +EQUALITY integerMatch
shadowWarning: +EQUALITY integerMatch
shadowInactive: +EQUALITY integerMatch
shadowExpire: +EQUALITY integerMatch
shadowFlag: +EQUALITY integerMatch
memberUid: +EQUALITY caseExactIA5Match
memberNisNetgroup: +EQUALITY caseExactIA5Match SUBSTR 
caseExactIA5SubstringsMatch
nisNetgroupTriple: +EQUALITY caseIgnoreIA5Match
ipServicePort: +EQUALITY integerMatch
ipServiceProtocol: +SUP name -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
ipProtocolNumber: +EQUALITY integerMatch
oncRpcNumber: +EQUALITY integerMatch
ipHostNumber: +SUP name -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
ipNetworkNumber: +SUP name -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
ipNetmaskNumber: +EQUALITY caseIgnoreIA5Match SYNTAX 
1.3.6.1.4.1.1466.115.121.1.26 -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
macAddress: +EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
-SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
bootParameter: +EQUALITY caseExactIA5Match
nisMapName: +SUP name -SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
nisMapEntry: +EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch

+ attributeTypes: ( 1.3.6.1.1.1.1.28 NAME 'nisPublicKey' DESC 'NIS public key' 
EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
+ attributeTypes: ( 1.3.6.1.1.1.1.29 NAME 'nisSecretKey' DESC 'NIS secret key' 
EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
+ attributeTypes: ( 1.3.6.1.1.1.1.30 NAME 'nisDomain' DESC 'NIS domain' 
EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+ attributeTypes: ( 1.3.6.1.1.1.1.31 NAME 'automountMapName' DESC 'automount 
Map Name' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+ attributeTypes: ( 1.3.6.1.1.1.1.32 NAME 'automountKey' DESC 'Automount Key 
value' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
+ attributeTypes: ( 1.3.6.1.1.1.1.33 NAME 'automountInformation' DESC 
'Automount information' EQUALITY caseExactIA5Match SUBSTR 
caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

posixAccount: 
shadowAccount: 
posixGroup: +AUXILLARY -MUST cn STRUCTURAL
ipService: 
ipProtocol: 
oncRpc:
ipHost: - MAY o $ ou $ owner $ seeAlso $ serialNumber +MAY userPassword 
ipNetwork: -MUST cn +MAY cn
nisNetgroup:
nisMap:
nisObject:
ieee802Device: -MUST cn MAY description $ l $ o $ ou $ owner $ seeAlso $ 
serialNumber
bootableDevice: -MUST cn MAY description $ l $ o $ ou $ owner $ seeAlso $ 
serialNumber 
nisMap: +OID 1.3.6.1.1.1.2.9 -OID 1.3.6.1.1.1.2.13

+ objectClasses: ( 1.3.6.1.1.1.2.14 NAME 'nisKeyObject' SUP top AUXILIARY DESC 
'An object with a public and secret key' MUST ( cn $ nisPublicKey $ 
nisSecretKey ) MAY ( uidNumber $ description ) )
+ objectClasses: ( 1.3.6.1.1.1.2.15 NAME 'nisDomainObject' SUP top AUXILIARY 
DESC 'Associates a NIS domain with a naming context' MUST nisDomain )
+ objectClasses: ( 1.3.6.1.1.1.2.16 NAME 'automountMap' SUP top STRUCTURAL MUST 
( automountMapName ) MAY description )
+ objectClasses: ( 1.3.6.1.1.1.2.17 NAME 'automount' SUP top STRUCTURAL DESC 
'Automount information' MUST ( automountKey $ automountInformation ) MAY 
description ) ## namedObject is needed for groups without members
+ objectClasses: ( 1.3.6.1.4.1.5322.13.1.1 NAME 'namedObject' SUP top 
STRUCTURAL MAY cn )



> 
>>> * ipServiceProtocol, ipHostNumber, ipNetworkNumber and nisMapName change 
>>> from "sup name" to 

[389-devel] Re: Thoughts on swapping to rfc2307bis.ldif by default

[William Brown]

> On 3 Mar 2020, at 04:32, thierry bordaz  wrote:
> 
> 
> 
> On 3/2/20 7:24 AM, William Brown wrote:
>> Hi all,
>> 
>> As you may know, I'm currently working on a migration utility to help move 
>> from other ldap servers to 389-ds. Something that I have noticed in this 
>> process is that other servers default to rfc2307bis.ldif [0] by default. As 
>> part of the migration I would like to handle this situation a bit better. 
>> It's likely not viable for me to simply plaster rfc2307bis into 99user.ldif 
>> as part of the migration process, so I want to approach this better.
>> 
>> rfc2307 and rfc2307bis are incompatible schemas that redefine the same OIDs 
>> with new/different meanings. Some key examples:
>> 
>> * posixGroup in rfc2307 only requires gidNumber, rfc2307bis requires cn and 
>> gidNumber.
> Is not it the opposite ?

I was reading the schema as I was reading this.

>> * ipServiceProtocol, ipHostNumber, ipNetworkNumber and nisMapName change 
>> from "sup name" to "syntax 1.3.6.1.4.1.1466.115.121.1.15". sup name is also 
>> syntax 1.3.6.1.4.1.1466.115.121.1.15 so this channge is minimal.
>> * posixGroup and posixAccount change from structural to auxillary in 
>> rfc2307bis (allowing them to be combined with person or nsAccount).
> Right but for 389-ds the structural requirement is not enforced, so it should 
> not be a problem

You know, that's probably actually the best thing I've heard all day. It makes 
this problem much easier. 

>> 
>> Objectively, rfc2307bis is the better schema - but as with all proposals 
>> like this, there is always a risk of breaking customers or compatibility.
> I agree on both :)
>> 
>> I'm wondering what would be a reasonable course of action for us to move to 
>> rfc2307bis by default. My current thoughts:
>> 
>> * have rfc2307bis vs rfc2307 as an option to dssetup so we use the correct 
>> schema in the setup.
>> * default the setup option to rfc2307bis
>> * Tests for handling both setup options
>> * Upgrades of the server should not affect the rfc2307 vs rfc2307bis status
>> * A dsctl tool to allow changing between the rfc2307/rfc2307bis.
>> 
>> Thoughts? Concern? Ideas? Comments?
> It would be interesting to have a complete list of the differences. at the 
> moment with the listed differences I think 2307bis would support 2307 
> entries. In addition, 2307bis looks to be a superset of 2307 so that it would 
> be replicated in a mmr topology.

Right. I'll get a list of all the differences, and knowing that structural 
isn't enforced does make things easier - a lot easier. It may be less 
disruptive to swap to 2307bis by default if that's the case. 

> 
> Because of some bug,  99user.ldif will contains all overridden definitions 
> not the only new/changed one.
> 
> The idea of a dsctl tool looks good. It could be to create a task that check 
> all entries conform a schema. If all entries conform 2307bis we could replace 
> the default 2307 schema file with the 2307bis.

Yeah, a task could help here too. 

>> 
>> 
>> [0] https://tools.ietf.org/html/draft-howard-rfc2307bis-02
>> 
>> —
>> Sincerely,
>> 
>> William Brown
>> 
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>> ___
>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

—
Sincerely,

William Brown

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

Re: Ideas and proposal for removing changelog and release fields from spec file

[clime]

Ad. Zbyszek:

> What about doing --.?
> This means that upgrade path not affected by the number of commits or
> builds in the older release.

I was thinking how to properly implement this into rpkg-util and then
finally, it clicked for me.

First, I added the prefix parameter for git_release macro (below
git_dir_release is used instead, which is the recommended form). Hence
now, one can specify:

Release: {{{ git_dir_release prefix="0%{?dist}" }}}

which would produce release strings like:

0.fc32.1
0.fc32.2
0.fc32.3

for each tag in f32 branch. The leading zero is not used here for
anything but without it, we would get NVRs like somepkg-1.0-.fc32.1 -
i.e. dash would be followed by immediate dot, which is not actually
invalid but it is strange.

Then it came to me that instead of %{dist} we can simply use branch
name and hence (finally) drop "c" from .fcXY:

Release: {{{ git_dir_release prefix="$GIT_BRANCH" }}}

("$GIT_BRANCH" is a macro variable that gives you name of the
currently checked out branch)

This will not work for cases when people put some special stuff into
%{dist} like Nicolas showed:
https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/fedora-release.spec#_488
but it would work for simple cases and fallback would be possible.

Finally, one can just alias `git_dir_release prefix="$GIT_BRANCH"`
with `git_dir_release_branched`
(https://pagure.io/rpkg-util/blob/master/f/macros/macros.d/git.bash#_464)
and hence get the following:

Release: {{{ git_dir_release_branched }}}

which will be bumping release with respect to the latest tag on the
current branch as well as the commits stacked on top of that tag (it
will be also bumping release for uncommitted work if your working tree
is dirty but i don't want to show it here now because NVRs are then
quite long).

I've prepared a test project for this new macro:
https://pagure.io/hello_rpkg_release. You need the latest "rpkg" and
"rpkg-macros" from
https://copr.fedorainfracloud.org/coprs/clime/rpkg-util/ for it to
work. But I also just dumped the results here:
https://pagure.io/hello_rpkg_release/tree/result . You can see what
NVRs are generated (by `rpkg nvr` command) at each particular point
for the given branch (i.e. hello_rpkg_release-1.14.0-f32.2 for the
second tagged commit in f32 branch) -- they are written down after the
"-->" arrow. I mention there three NVRs in total:

hello_rpkg_release-1.14.0-master.1  (the first tagged commit master branch
hello_rpkg_release-1.14.0-f32.2  (the second tagged commit in the f32 branch)
hello_rpkg_release-1.14.0-f31.1.git.1.34684da9  (untagged commit on
top of the first tagged commit in the f31 branch)

Any feedback welcome.

On Mon, 2 Mar 2020 at 14:51, Neal Gompa  wrote:
>
> On Mon, Mar 2, 2020 at 8:46 AM clime  wrote:
> >
> > On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
> >  wrote:
> > >
> > > If you don’t keep things decentralized you’ll be in a word of pain when
> > > the scm or buildsys needs to be changed for another implementation (not
> > > to mention, that’s not a good way to collaborate with other distros).
> > > That will happen eventually. Web apps are not eternal.
> >
> > Full decentralization likely means that everyone has its own git repo
> > and we can only sync by mailing list. I think src.fp.o is a good point
> > where things can be done and where we can agree on what the packages
> > that Fedora produce are (meaning we need a canonical source of package
> > sources, otherwise it would be more complex to put a distribution
> > together).
> >
>
> This is not true. Pagure accepts PRs from arbitrary Git servers just
> fine via the remote PR feature, so we do support decentralized
> workflows without resorting to sending patches via email or Bugzilla.
>
>
>
> --
> 真実はいつも一つ！/ 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[rpms/perl-Test-mysqld] PR #1: Use the correct name of the required package

[Denis Fateyev]

dfateyev merged a pull-request against the project: `perl-Test-mysqld` that you 
are following.

Merged pull-request:

``
Use the correct name of the required package
``

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

Re: Strange covert module builds [sbergmann ?]

[Colin Walters]

On Mon, Mar 2, 2020, at 9:14 AM, Kalev Lember wrote:

> For extra libraries that app flatpaks need that are not part of the
> runtime, those we rebuild for the /app prefix for each app, using the MBS.

I think whenever discussing this, it needs to be stated clearly that the 
*reason* for using the /app prefix is that flatpaks are *dynamically* linked 
against the runtime (a big contrast with the Docker/OCI model).By storing 
the app data in /app it avoids any "physical" conflicts when the two are 
layered together.  This should probably be at 
http://docs.flatpak.org/en/latest/basic-concepts.html and then we can just link 
to it or so.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Non-Responsive Maintainer: bsjones

[Erich Eickmeyer]

Hello all,

I have had zero success in contacting Brendan Jones per the non-responsive 
maintainer checks I filed in Bugzilla:

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

Additionally, I attempted a pull request on fedora-jam-backgrounds that got 
met with no response.

As these attempts were over a week ago, I guess my next step is to submit a 
FESCo issue with the bug links. However, since this is my first post 
specifically looking for bsjones unlike my previous post, perhaps I should 
give it another week? Or, does my previous post looking to adopt fedora-jam-
backgrounds and fedora-jam-kde-theme count for that? If not, I'll err on the 
side of giving it another week.

Thanks,
Erich

Erich Eickmeyer
Fedora Jam

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

Spend 5 minutes on reviewing a quick-doc!

[Ankur Sinha]

Hello!

There are still a lot of quick-docs that were automatically converted
from wiki pages that have not yet been reviewed for correctness. If you
have a few minutes, please pick one and check it to see if the
information is correct and up to date.

https://docs.fedoraproject.org/en-US/quick-docs/

I've opened some tickets that folks can take up, mostly for newcomers.

https://pagure.io/fedora-docs/quick-docs/issues

There are lots of pages that I've not created tickets for yet. If you
take one of those up, please open a ticket to let folks know that you
are working on it.

Honestly, most of these are so simple, 5 minutes is all it'll take!
You'll get a cookie from me on IRC as a reward!! A whole cookie!! :D

For any questions, please head to the docs channels/mailing list:
#fedora-docs, d...@lists.fedoraproject.org

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


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

[Bug 1808774] perl-List-AllUtils-0.16 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-List-AllUtils-0.16-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-20d470827f

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

[Bug 1808956] perl-Encode-3.03 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Encode-3.03-441.fc31 has been pushed to the Fedora 31 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-92090d32ac

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

[Bug 1808816] perl-String-Print-0.94 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-String-Print-0.94-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-06bc9ab50e

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

[Bug 1805545] perl-CPAN-Perl-Releases-5.20200220 is available

[bugzilla]

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



--- Comment #12 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200229-1.fc31 has been pushed to the Fedora 31
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-096e6625d8

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

[Bug 1808744] perl-CPAN-Perl-Releases-5.20200229 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200229-1.fc31 has been pushed to the Fedora 31
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-096e6625d8

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

[Bug 1809016] perl-Time-Out EPEL8

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Time-Out-0.11-18.el8 has been pushed to the Fedora EPEL 8 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-f0f26b46b3

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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-3483348dc1   
proftpd-1.3.6c-1.el8
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-47a203cb95   
openfortivpn-1.12.0-1.el8


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

cacti-1.2.10-1.el8
cacti-spine-1.2.10-1.el8
earlyoom-1.4-1.el8
libabigail-1.7-1.el8
perl-Time-Out-0.11-18.el8

Details about builds:



 cacti-1.2.10-1.el8 (FEDORA-EPEL-2020-9d364c6070)
 An rrd based graphing tool

Update Information:

- Update to 1.2.10 - CVE-2020-8813  Release notes:
https://www.cacti.net/release_notes.php?version=1.2.10

ChangeLog:

* Mon Mar  2 2020 Morten Stevens  - 1.2.10-1
- Update to 1.2.10
- CVE-2020-8813




 cacti-spine-1.2.10-1.el8 (FEDORA-EPEL-2020-9d364c6070)
 Threaded poller for Cacti written in C

Update Information:

- Update to 1.2.10 - CVE-2020-8813  Release notes:
https://www.cacti.net/release_notes.php?version=1.2.10

ChangeLog:

* Mon Mar  2 2020 Morten Stevens  - 1.2.10-1
- Update to 1.2.10




 earlyoom-1.4-1.el8 (FEDORA-EPEL-2020-a34c1640f1)
 Early OOM Daemon for Linux

Update Information:

  * Make victim selection logic 50% faster by lazy-loading process attributes
* Log the user id `uid` of killed processes in addition to pid and name   *
Color debug log in light grey   * Code clean-up * Use block-local variables
where possible * Introduce PATH_LEN to replace several hardcoded buffer
lengths   * Expand testsuite (`make test`)   * Run `cppcheck` when available   *
Add unit-test benchmarks (`make bench`)   * Drop root privileges in systemd unit
file `earlyoom.service`     Updated to version 1.3.1.

ChangeLog:

* Mon Mar  2 2020 Vitaly Zaitsev  - 1.4-1
- Updated to version 1.4.
* Fri Feb 28 2020 Vitaly Zaitsev  - 1.3.1-1
- Updated to version 1.3.1.
* Fri Feb 21 2020 Vitaly Zaitsev  - 1.3-4
- Rebuilt for Fedora 32.
- Backported security hardening patches.




 libabigail-1.7-1.el8 (FEDORA-EPEL-2020-ad59a4bc5c)
 Set of ABI analysis tools

Update Information:

Update to upstream 1.7

ChangeLog:

* Mon Mar  2 2020 Dodji Seketeli  - 1.7-1
- Update to upstream 1.7
  - Add Koji as BuildRequires
  Fixes: RHBZ#1799575




 perl-Time-Out-0.11-18.el8 (FEDORA-EPEL-2020-f0f26b46b3)
 Easily time out long running operations

Update Information:

This erratum brings a new perl-Time-Out package that enables you to time out
long running tasks in Perl.

ChangeLog:

* Mon Mar  2 2020 Petr Pisar  -  0.11-18
- Modernize a spec file
* Thu Jan 30 2020 Fedora Release Engineering  - 
0.11-17
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Fri Jul 26 2019 Fedora Release Engineering  - 
0.11-16
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Fri May 31 2019 Jitka Plesnikova  - 0.11-15
- Perl 5.30 rebuild
* Sat Feb  2 2019 Fedora Release Engineering  - 
0.11-14
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Fri Jul 13 2018 Fedora Release Engineering  - 
0.11-13
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Thu Jun 28 2018 Jitka Plesnikova  - 0.11-12
- Perl 5.28 rebuild
* Fri Feb  9 2018 Fedora Release Engineering  - 
0.11-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Jul 27 2017 Fedora Release Engineering  - 
0.11-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Sun Jun  4 2017 Jitka 

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 565  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d   
condor-8.6.11-1.el7
 307  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80   
python-gnupg-0.4.4-1.el7
 305  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b   
bubblewrap-0.3.3-2.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6   
python-waitress-1.4.3-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-99abadf4df   
python-psutil-5.6.7-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b1046cc65d   
python-colander-1.7.0-1.el7
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5f252e8e10   
kea-1.6.0-4.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ea579d7782   
proftpd-1.3.5e-9.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b57b954fde   
openfortivpn-1.12.0-1.el7


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

cacti-1.2.10-1.el7
cacti-spine-1.2.10-1.el7
php-composer-xdebug-handler-1.4.1-1.el7

Details about builds:



 cacti-1.2.10-1.el7 (FEDORA-EPEL-2020-1f5dbc1cd7)
 An rrd based graphing tool

Update Information:

- Update to 1.2.10 - CVE-2020-8813  Release notes:
https://www.cacti.net/release_notes.php?version=1.2.10

ChangeLog:

* Mon Mar  2 2020 Morten Stevens  - 1.2.10-1
- Update to 1.2.10
- CVE-2020-8813




 cacti-spine-1.2.10-1.el7 (FEDORA-EPEL-2020-1f5dbc1cd7)
 Threaded poller for Cacti written in C

Update Information:

- Update to 1.2.10 - CVE-2020-8813  Release notes:
https://www.cacti.net/release_notes.php?version=1.2.10

ChangeLog:

* Mon Mar  2 2020 Morten Stevens  - 1.2.10-1
- Update to 1.2.10




 php-composer-xdebug-handler-1.4.1-1.el7 (FEDORA-EPEL-2020-5d0f22b886)
 Restarts a process without Xdebug

Update Information:

**Version 1.4.1** - 2020-03-01  * Fixed: restart fails if an ini file is empty.

ChangeLog:

* Mon Mar  2 2020 Remi Collet  - 1.4.1-1
- update to 1.4.1


___
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 1805545] perl-CPAN-Perl-Releases-5.20200220 is available

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
perl-Module-CoreList-5.20200220-1.fc31 has been pushed to the Fedora 31 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1805545] perl-CPAN-Perl-Releases-5.20200220 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-03-02 18:51:04



--- Comment #10 from Fedora Update System  ---
perl-Module-CoreList-5.20200220-1.fc30 has been pushed to the Fedora 30 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1805545] perl-CPAN-Perl-Releases-5.20200220 is available

[bugzilla]

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



--- Comment #9 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200229-1.fc30 has been pushed to the Fedora 30
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-81dde32327

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

[Bug 1808774] perl-List-AllUtils-0.16 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-List-AllUtils-0.16-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-25768a1a3a

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

[Bug 1808956] perl-Encode-3.03 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Encode-3.03-12.fc30 has been pushed to the Fedora 30 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-c4f2c2c7ab

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

[Bug 1808744] perl-CPAN-Perl-Releases-5.20200229 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200229-1.fc30 has been pushed to the Fedora 30
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-81dde32327

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

[Bug 1808816] perl-String-Print-0.94 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-String-Print-0.94-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a75aef5b6a

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

[389-devel] Re: Thoughts on swapping to rfc2307bis.ldif by default

[thierry bordaz]

On 3/2/20 7:24 AM, William Brown wrote:

Hi all,

As you may know, I'm currently working on a migration utility to help move from 
other ldap servers to 389-ds. Something that I have noticed in this process is 
that other servers default to rfc2307bis.ldif [0] by default. As part of the 
migration I would like to handle this situation a bit better. It's likely not 
viable for me to simply plaster rfc2307bis into 99user.ldif as part of the 
migration process, so I want to approach this better.

rfc2307 and rfc2307bis are incompatible schemas that redefine the same OIDs 
with new/different meanings. Some key examples:

* posixGroup in rfc2307 only requires gidNumber, rfc2307bis requires cn and 
gidNumber.

Is not it the opposite ?

* ipServiceProtocol, ipHostNumber, ipNetworkNumber and nisMapName change from "sup name" 
to "syntax 1.3.6.1.4.1.1466.115.121.1.15". sup name is also syntax 
1.3.6.1.4.1.1466.115.121.1.15 so this channge is minimal.
* posixGroup and posixAccount change from structural to auxillary in rfc2307bis 
(allowing them to be combined with person or nsAccount).
Right but for 389-ds the structural requirement is not enforced, so it 
should not be a problem


Objectively, rfc2307bis is the better schema - but as with all proposals like 
this, there is always a risk of breaking customers or compatibility.

I agree on both :)


I'm wondering what would be a reasonable course of action for us to move to 
rfc2307bis by default. My current thoughts:

* have rfc2307bis vs rfc2307 as an option to dssetup so we use the correct 
schema in the setup.
* default the setup option to rfc2307bis
* Tests for handling both setup options
* Upgrades of the server should not affect the rfc2307 vs rfc2307bis status
* A dsctl tool to allow changing between the rfc2307/rfc2307bis.

Thoughts? Concern? Ideas? Comments?
It would be interesting to have a complete list of the differences. at 
the moment with the listed differences I think 2307bis would support 
2307 entries. In addition, 2307bis looks to be a superset of 2307 so 
that it would be replicated in a mmr topology.


Because of some bug,  99user.ldif will contains all overridden 
definitions not the only new/changed one.


The idea of a dsctl tool looks good. It could be to create a task that 
check all entries conform a schema. If all entries conform 2307bis we 
could replace the default 2307 schema file with the 2307bis.



[0] https://tools.ietf.org/html/draft-howard-rfc2307bis-02

—
Sincerely,

William Brown

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

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

Fedora-IoT-32-20200302.0 compose check report

[Fedora compose checker]

Missing expected images:

Iot dvd x86_64
Iot dvd aarch64

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-32-20200228.0):

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

Passed openQA tests: 6/8 (x86_64)

New passes (same test not passed in Fedora-IoT-32-20200228.0):

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

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
1 services(s) added since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-0f0bc31b\x2dc624\x2d443c\x2da704\x2da7070ebedc92.service
1 services(s) removed since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-94b32a0b\x2d41ce\x2d4b32\x2da60d\x2d31caa5376ca7.service
Previous test data: https://openqa.fedoraproject.org/tests/529727#downloads
Current test data: https://openqa.fedoraproject.org/tests/530758#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
2 services(s) added since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-36C6\x2d9573.service,   
systemd-fsck@dev-disk-by\x2duuid-7961054d\x2dbf51\x2d413c\x2d9492\x2d100e7ffcbb95.service
2 services(s) removed since previous compose:   
systemd-fsck@dev-disk-by\x2duuid-D1B6\x2d42AC.service,   
systemd-fsck@dev-disk-by\x2duuid-c5e8976c\x2dcaa0\x2d4d7e\x2dbf39\x2d50d51ac9272a.service
Previous test data: https://openqa.fedoraproject.org/tests/529728#downloads
Current test data: https://openqa.fedoraproject.org/tests/530759#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

Fedora-32-20200302.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 23/171 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-32-20200301.n.0):

ID: 530704  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/530704

Old failures (same test failed in Fedora-32-20200301.n.0):

ID: 530598  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/530598
ID: 530600  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/530600
ID: 530624  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/530624
ID: 530631  Test: x86_64 Workstation-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/530631
ID: 530648  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/530648
ID: 530655  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/530655
ID: 530664  Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/530664
ID: 530678  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/530678
ID: 530679  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/530679
ID: 530681  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/530681
ID: 530683  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/530683
ID: 530684  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/530684
ID: 530693  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/530693
ID: 530694  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/530694
ID: 530701  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/530701
ID: 530706  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/530706
ID: 530709  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/530709
ID: 530722  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/530722
ID: 530734  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/530734
ID: 530741  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/530741
ID: 530742  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/530742
ID: 530747  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/530747
ID: 530748  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/530748

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

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

ID: 530579  Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/530579
ID: 530602  Test: x86_64 Server-dvd-iso realmd_join_sssd
URL: https://openqa.fedoraproject.org/tests/530602
ID: 530614  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/530614
ID: 530634  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/530634

Old soft failures (same test soft failed in Fedora-32-20200301.n.0):

ID: 530576  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/530576
ID: 530577  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/530577
ID: 530581  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/530581
ID: 530584  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/530584
ID: 530585  Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/530585
ID: 530605  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/530605
ID: 530636  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/530636
ID: 530668  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/530668
ID: 530677  Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/530677
ID: 530695  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/530695
ID: 530730  Test: x86_64 universal upgrade_2_kde_64bit
URL: 

[EPEL-devel] Re: Ansible & Python 3 in EPEL7

[Neal Gompa]

On Mon, Mar 2, 2020 at 12:19 PM Carl George  wrote:
>
> The EL7 python3 stack does not have all the same libraries available.
> Ansible users have already complained about the lack of libselinux
> bindings, but thankfully that should be resolved in 7.8.
>
> https://bugs.centos.org/view.php?id=16389
> https://bugzilla.redhat.com/show_bug.cgi?id=1719978
> https://git.centos.org/rpms/libselinux/blob/c7-beta/f/SPECS/libselinux.spec#_259
>

Missing DNF stack Python 3 modules means that the yum module will be broken
in Python 3 too.




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

[EPEL-devel] Re: Ansible & Python 3 in EPEL7

[Carl George]

The EL7 python3 stack does not have all the same libraries available.
Ansible users have already complained about the lack of libselinux
bindings, but thankfully that should be resolved in 7.8.

https://bugs.centos.org/view.php?id=16389
https://bugzilla.redhat.com/show_bug.cgi?id=1719978
https://git.centos.org/rpms/libselinux/blob/c7-beta/f/SPECS/libselinux.spec#_259

On Mon, Mar 2, 2020 at 4:47 AM Igor Gnatenko  wrote:
>
> Hey folks,
>
> We recently started to use Ansible more and we are using some ansible
> collection which is not compatible with Python 2.
>
> Are there any plans to switch Ansible to Python 3 in EPEL7 or are
> there any recommendations what to do in such cases as we have?
> --
> -Igor Gnatenko
> ___
> 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



-- 
Carl George
___
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

Reminder: Summer time changes in the next few weeks

[Ben Cotton]

As a reminder to the community, we've reached the point in the year
where jurisdictions around the world begin or end summer time. Be sure
to check your recurring meetings on Fedocal[1] to make sure you know
when you're meeting. Some meetings are set to a fixed time UTC and
others are set to a particular time zone.

A global list of time changes is available by country[2] and by
date[3], but here are a few highlights:

* Sun 8 March: US, Canada, Mexico (and others) begin observing summer time
* Sun 29 March: UK, Europe (and others) begin observing summer time
* Sun 5 April: Australia (and others) stop observing summer time


[1] https://apps.fedoraproject.org/calendar/
[2] https://www.timeanddate.com/time/dst/2020.html
[3] https://www.timeanddate.com/time/dst/2020a.html

-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GNOME 3.35.92 megaupdate

[Kalev Lember]

On 3/2/20 14:55, Kalev Lember wrote:


Hi all,

I am putting together a megaupdate for GNOME 3.35.92. If you are helping 
with builds, please wait until we have the f32-gnome side tag (requested 
in https://pagure.io/releng/issue/9292) and then do the F32 builds with 
'fedpkg build --target f32-gnome'. I'll collect all the builds tagged 
with f32-gnome for the megaupdate and submit them to Bodhi all together.


OK, the side tag should be in place now.

--
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1808774] perl-List-AllUtils-0.16 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-List-AllUtils-0.16-1.fc32 has been pushed to the Fedora 32 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a7791f2af4

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

[Bug 1808730] perl-DateTime-1.52 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-DateTime-1.52-1.fc32 has been pushed to the Fedora 32 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-92d15ce212

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

[Bug 1808731] perl-DateTime-Format-Strptime-1.77 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #1 from Fedora Update System  ---
perl-DateTime-Format-Strptime-1.77-1.fc32 has been pushed to the Fedora 32
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-751977d0d1

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

[Bug 1808816] perl-String-Print-0.94 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-String-Print-0.94-1.fc32 has been pushed to the Fedora 32 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-b12803c8b4

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

[Bug 1808956] perl-Encode-3.03 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
perl-Encode-3.03-442.fc32 has been pushed to the Fedora 32 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-6f64955abd

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

[Bug 1808744] perl-CPAN-Perl-Releases-5.20200229 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-CPAN-Perl-Releases-5.20200229-1.fc32 has been pushed to the Fedora 32
testing repository. If problems still persist, please make note of it in this
bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-62bcc133fe

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

[Bug 1809214] perl-Test-Deep-1.130 is available

[bugzilla]

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



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

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

[Bug 1809214] perl-Test-Deep-1.130 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Test-Deep-1.130-1.fc33
   ||perl-Test-Deep-1.130-1.fc32
 Resolution|--- |RAWHIDE
Last Closed||2020-03-02 16:09:37



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

[Bug 1809214] perl-Test-Deep-1.130 is available

[bugzilla]

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

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

Fedora 32 compose report: 20200302.n.0 changes

[Fedora Branched Report]

OLD: Fedora-32-20200301.n.0
NEW: Fedora-32-20200302.n.0

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

Size of added packages:  0 B
Size of dropped packages:359.47 KiB
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 =
Package: python-nineml-1.0.1-2.fc31
Summary: A tool for reading, writing and generally working with 9ML
RPMs:python-nineml-doc python3-nineml
Size:359.47 KiB


= 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

[Bug 1804272] Upgrade perl-Convert-UUlib to 1.7

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

Summary|Upgrade perl-Convert-UUlib  |Upgrade perl-Convert-UUlib
   |to 1.62 |to 1.7



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

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

Re: GCC help needed for chromium

[Michael Catanzaro]

On Mon, Mar 2, 2020 at 8:57 am, Tom Callaway  
wrote:
 // This horrible const_cast pattern is necessary to work 
around a constexpr limitation.
 // See https://stackoverflow.com/q/34199774/ . Note that 
it should be fixed with C++17.

 const_cast(const_cast(

mPrivateData)[static_cast(it->first)]) = it->second;


FYI, there is an upstream bug here:
https://bugs.chromium.org/p/angleproject/issues/detail?id=4390

But sadly, you've already found the solution there doesn't work for 
you


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

[bugzilla]

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



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

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

[Bug 1809016] perl-Time-Out EPEL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Time-Out-0.11-18.el8
   ||perl-Time-Out-0.11-18.epel8
   ||.playground



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

[Bug 1809214] New: perl-Test-Deep-1.130 is available

[bugzilla]

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

Bug ID: 1809214
   Summary: perl-Test-Deep-1.130 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Test-Deep
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, st...@silug.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.130
Current version/release in rawhide: 1.128-7.fc32
URL: http://search.cpan.org/dist/Test-Deep/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/11907/

-- 
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: EPEL Steering Committee Meeting Time

[Troy Dawson]

On Fri, Feb 21, 2020 at 2:12 PM Troy Dawson  wrote:
>
> On Fri, Feb 21, 2020 at 12:57 PM Kevin Fenzi  wrote:
> >
> > On Fri, Feb 21, 2020 at 12:11:19PM -0800, Troy Dawson wrote:
> > > It seems that it is a tradition that when we have a new chair for the
> > > EPEL steering committee, we also have a new time for meeting.
> > > Something that fits better with all the current, active members.
> > >
> > > We currently have the meeting on Wedensdays at 1800 UTC.
> > > date -d "Wed 1800 UTC"
> > > 1:00pm Eastern U.S.  10:00am Pacific U.S. 02:00am Beijing China
> > >
> > > What day and time would people like?
> > > If you haven't been able to come to the meeting due to the time, what
> > > would be best for you?
> >
> > Perhaps we should make a https://whenisgood.net/ or whatever that fully
> > open source one is ( frame a date?), and let people vote for a week or
> > so?
> >
> > kevin
>
> Sounds good.
> It is framadate.  It just happens to sounds like frame a date.
> I have setup a "poll" for Monday through Friday.  I did the times a
> bit to the extreme, from very very early for those on the U.S. west
> coast, to very very late for those in Europe.
> I sorta hope neither of those extremes are picked, but I figured it
> would be best to have everything.
>
> https://framadate.org/hXYmD86z3U5jTXqm
>
> Troy

Thus far the most votes are for:

Tuesday,  1700 UTC : Yes (5) IfNeedBe (0)
Thursday, 1600 UTC : Yes (5) IfNeedBe (0)
Thursday, 1700 UTC : Yes (5) IfNeedBe (0)
Friday,  1700 UTC : Yes (5) IfNeedBe (0)
Friday,  2100 UTC : Yes (5) IfNeedBe (1)
Friday,  2200 UTC : Yes (5) IfNeedBe (1)

This looks like Friday at 2100 or 2200 are best.
I'm not a big fan of meetings on Fridays, or Mondays, due to holiday conflicts.
I'll do it, if that is what everyone wants, it's just not my favorite.

Here are some of the runner up times.

Tuesday,  2100 UTC : Yes (4) IfNeedBe (1)
Tuesday,  2200 UTC : Yes (4) IfNeedBe (1)
Wednesday,  2200 UTC : Yes (4) IfNeedBe (1)
Thursday,  2200 UTC : Yes (4) IfNeedBe (1)
Thursday,  1800 UTC : Yes (3) IfNeedBe (2)

Troy
p.s. Yes, this weeks meeting is at the usual time.  Whatever we decide
on will be for the following week. (March 9-13)
___
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: Fwd: How to update ? Was:[Red Hat Bugzilla] Your Outstanding Requests

[Michael Catanzaro]

On Mon, Mar 2, 2020 at 1:55 pm, Petr Pisar  wrote:

Then tick on "I am providing the requested information for this
bug" item under the large comment text area.


That was probably the key point. Bugzilla was reminding you that you 
had an unresolved needinfo in that bug.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1809202] New: perl-Date-Manip-6.80 is available

[bugzilla]

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

Bug ID: 1809202
   Summary: perl-Date-Manip-6.80 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Date-Manip
  Keywords: FutureFeature, Triaged
  Assignee: jpazdzi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: huzai...@redhat.com, jpazdzi...@redhat.com,
ka...@ucw.cz, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 6.80
Current version/release in rawhide: 6.79-2.fc32
URL: http://search.cpan.org/dist/Date-Manip/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/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/2785/

-- 
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: kernel install - very slow weak modules / depmod step

[Richard W.M. Jones]

On Mon, Mar 02, 2020 at 02:22:54PM +, Richard W.M. Jones wrote:
> On Mon, Mar 02, 2020 at 02:17:35PM +, Richard W.M. Jones wrote:
> > I've been installing kernel-core-5.6.0-0.rc3.git2.2.fc33.x86_64 on a
> > very fast AMD server and it's taking many minutes (at least 5 minutes
> > and I'm still waiting).  The slow step seems t be running some new
> > thing called "weak-modules", and many depmod invocations underneath.
> > 
> >2212 pts/0S+ 0:01  |   \_ /usr/bin/bash 
> > /usr/sbin/weak-modules --add-kernel 5.6.0-0.rc3.git2.2.fc33.x
> >7905 pts/0R+ 0:02  |   \_ /sbin/depmod 
> > -C /tmp/weak-modules.0Ig9Wa/depmod.conf -naeE /tmp/weak-mo
> >7906 pts/0S+ 0:00  |   \_ grep 
> > /tmp/weak-modules.0Ig9Wa/5.6.0-0.rc3.git2.2.fc33.x86_64/weak-updat
> 
> This must be 10 minutes now and it's still going.

25 minutes and still going.  I have filed a bug:

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

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: kernel install - very slow weak modules / depmod step

[Richard W.M. Jones]

On Mon, Mar 02, 2020 at 02:17:35PM +, Richard W.M. Jones wrote:
> I've been installing kernel-core-5.6.0-0.rc3.git2.2.fc33.x86_64 on a
> very fast AMD server and it's taking many minutes (at least 5 minutes
> and I'm still waiting).  The slow step seems t be running some new
> thing called "weak-modules", and many depmod invocations underneath.
> 
>2212 pts/0S+ 0:01  |   \_ /usr/bin/bash 
> /usr/sbin/weak-modules --add-kernel 5.6.0-0.rc3.git2.2.fc33.x
>7905 pts/0R+ 0:02  |   \_ /sbin/depmod -C 
> /tmp/weak-modules.0Ig9Wa/depmod.conf -naeE /tmp/weak-mo
>7906 pts/0S+ 0:00  |   \_ grep 
> /tmp/weak-modules.0Ig9Wa/5.6.0-0.rc3.git2.2.fc33.x86_64/weak-updat

This must be 10 minutes now and it's still going.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

kernel install - very slow weak modules / depmod step

[Richard W.M. Jones]

I've been installing kernel-core-5.6.0-0.rc3.git2.2.fc33.x86_64 on a
very fast AMD server and it's taking many minutes (at least 5 minutes
and I'm still waiting).  The slow step seems t be running some new
thing called "weak-modules", and many depmod invocations underneath.

   2212 pts/0S+ 0:01  |   \_ /usr/bin/bash 
/usr/sbin/weak-modules --add-kernel 5.6.0-0.rc3.git2.2.fc33.x
   7905 pts/0R+ 0:02  |   \_ /sbin/depmod -C 
/tmp/weak-modules.0Ig9Wa/depmod.conf -naeE /tmp/weak-mo
   7906 pts/0S+ 0:00  |   \_ grep 
/tmp/weak-modules.0Ig9Wa/5.6.0-0.rc3.git2.2.fc33.x86_64/weak-updat

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GCC help needed for chromium

[Jakub Jelinek]

On Mon, Mar 02, 2020 at 08:57:46AM -0500, Tom Callaway wrote:
> Wait, I know that $TOPIC is scary, come back.
> 
> Chromium has this chunk of code (in
> third_party/angle/src/common/PackedEnums.h):
> 
>  // This horrible const_cast pattern is necessary to work
> around a constexpr limitation.
>  // See https://stackoverflow.com/q/34199774/ . Note that it
> should be fixed with C++17.
>  const_cast(const_cast(
> mPrivateData)[static_cast(it->first)]) =
> it->second;
> 
> This code built with gcc9, but with gcc10 it no longer works.

Is it now rejected with some error (which)?
Generally, such code snippets aren't really very useful because they lack
context, so what we really need is full preprocessed sources + g++ command
line options used to reproduce it, if gcc9 built and gcc10 doesn't, best
preprocessed sources from both gcc 9 and gcc 10, so that we can find out if
it is a header change or compiler change that matters.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Strange covert module builds [sbergmann ?]

[Kalev Lember]

On 3/2/20 14:15, Michal Schorm wrote:

That new thing then gets leveraged into the next new thing with multiple layers 
that would make MC Escher and Rube Goldberg proud.

Awesome :D ...

TL;DR:
I don't need to investigate it further.
I was afraid of rouge Fedora Module builds, which actually didn't happen.

If flatpack needs to rebuild everything for them again, it's a pity
(from the infrastructure load POV), but I'd guess there's no other way
currently.


Yes. Flatpaks have two components: a runtime flatpak and an app flatpak.

For the Fedora flatpak runtime we reuse existing rpm builds and just
ship them in a different format. This is possible because runtimes use
/usr prefix, same as regular Fedora rpms.

For extra libraries that app flatpaks need that are not part of the
runtime, those we rebuild for the /app prefix for each app, using the MBS.

What you were seeing here were some libraries getting rebuilt for
inclusion in the libreoffice flatpak. They are part of the libreoffice
module. We can't use the existing rpm builds because they are built for
the wrong prefix (/usr vs /app).

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

[Kalev Lember]

On 3/2/20 15:04, Richard Shaw wrote:
On Mon, Mar 2, 2020 at 7:57 AM Kalev Lember > wrote:



Hi all,

I am putting together a megaupdate for GNOME 3.35.92. If you are
helping
with builds, please wait until we have the f32-gnome side tag
(requested
in https://pagure.io/releng/issue/9292) and then do the F32 builds with
'fedpkg build --target f32-gnome'. I'll collect all the builds tagged
with f32-gnome for the megaupdate and submit them to Bodhi all together.


I thought you could just use 'fedpkg request-side-tag [...]" at this point?


Yes, but this is meant for short lived side tags, not for something that 
we keep around for months to coordinate updates between a number of people.


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

Plan to retire mapserver

[Julien Enselme]

Hi all,

I intend to retire the mapserver package 
(https://src.fedoraproject.org/rpms/mapserver). I don't use it any more and it 
fails to build for F32. If you want to maintain it, please step up!

Regards,
-- 
Julien Enselme
http://www.jujens.eu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: GNOME 3.35.92 megaupdate

[Richard Shaw]

On Mon, Mar 2, 2020 at 7:57 AM Kalev Lember  wrote:

>
> Hi all,
>
> I am putting together a megaupdate for GNOME 3.35.92. If you are helping
> with builds, please wait until we have the f32-gnome side tag (requested
> in https://pagure.io/releng/issue/9292) and then do the F32 builds with
> 'fedpkg build --target f32-gnome'. I'll collect all the builds tagged
> with f32-gnome for the megaupdate and submit them to Bodhi all together.
>

I thought you could just use 'fedpkg request-side-tag [...]" at this point?

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

GCC help needed for chromium

[Tom Callaway]

Wait, I know that $TOPIC is scary, come back.

Chromium has this chunk of code (in
third_party/angle/src/common/PackedEnums.h):

 // This horrible const_cast pattern is necessary to work
around a constexpr limitation.
 // See https://stackoverflow.com/q/34199774/ . Note that it
should be fixed with C++17.
 const_cast(const_cast(
mPrivateData)[static_cast(it->first)]) =
it->second;

This code built with gcc9, but with gcc10 it no longer works.

I've tried two ways to fix this:

A) Changing that line of code to:

   mPrivateData[static_cast(it->first)] = it->second;

AND

  Building all of chromium with -std=c++17

This results in a chromium that builds but segfaults immediately:

Stack trace of thread 333141:
#0  0x56480cc9b2d8
_Z41__static_initialization_and_destruction_0ii.constprop.0
(chromium-browser + 0x6b82d8)
#1  0x56480f130dfd __libc_csu_init (chromium-browser +
0x2b4ddfd)
#2  0x7f0a04a2cfce __libc_start_main (libc.so.6 +
0x26fce)
#3  0x56480ccaf21e _start (chromium-browser + 0x6cc21e)

B) Cheating and accessing the std::array's underlying array directly
(thanks to Raphael Kubo Da Costa for the idea):

   mPrivateData._M_elems[static_cast(it->first)] =
it->second;

That change enables chromium to build, but it segfaults in the same way.

Now, it's possible that this change is a red herring and that something
else in GCC10 is causing the segfault, but I'm out of ideas on how to
proceed. If someone with GCC knowhow could help out here, it would be
greatly appreciated.

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

GNOME 3.35.92 megaupdate

[Kalev Lember]

Hi all,

I am putting together a megaupdate for GNOME 3.35.92. If you are helping 
with builds, please wait until we have the f32-gnome side tag (requested 
in https://pagure.io/releng/issue/9292) and then do the F32 builds with 
'fedpkg build --target f32-gnome'. I'll collect all the builds tagged 
with f32-gnome for the megaupdate and submit them to Bodhi all together.


Same drill next week for 3.36.0 release.

Thanks!

--
Kalev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Ideas and proposal for removing changelog and release fields from spec file

[Neal Gompa]

On Mon, Mar 2, 2020 at 8:46 AM clime  wrote:
>
> On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
>  wrote:
> >
> > If you don’t keep things decentralized you’ll be in a word of pain when
> > the scm or buildsys needs to be changed for another implementation (not
> > to mention, that’s not a good way to collaborate with other distros).
> > That will happen eventually. Web apps are not eternal.
>
> Full decentralization likely means that everyone has its own git repo
> and we can only sync by mailing list. I think src.fp.o is a good point
> where things can be done and where we can agree on what the packages
> that Fedora produce are (meaning we need a canonical source of package
> sources, otherwise it would be more complex to put a distribution
> together).
>

This is not true. Pagure accepts PRs from arbitrary Git servers just
fine via the remote PR feature, so we do support decentralized
workflows without resorting to sending patches via email or Bugzilla.



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

[Bug 1808731] perl-DateTime-Format-Strptime-1.77 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-DateTime-Format-Strpti
   ||me-1.77-1.fc33
   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: Ideas and proposal for removing changelog and release fields from spec file

[clime]

On Mon, 2 Mar 2020 at 12:05, Nicolas Mailhot via devel
 wrote:
>
> Le 2020-03-01 02:31, clime a écrit :
> > On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
> >  wrote:
> >>
> >> Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :
>
> >> Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
> >> detached file state means that fedpkg local (or checking out git state
> >> and building in mock or copr or OBS or via plain rpmbuild -bs) will
> >> give you the same result as launching fedpkg build.
> >
> > Well, I believe it doesn't. You run:
> >
> > 1) fedpkg local -> produces -1.0-1.fc32 (1 in release because
> > you haven't built that package before)
> > 2) fedpkg build
>
> At that point state is undefined till the build succeeds or not. If the
> build succeeds, the buildsystem will write back a new state. Let’s
> assume it succeeds.

It's undefined if you add more elements to the equation than necessary
(i.e. build system), otherwise it would be well-defined in this case.

>
> > 3) vim .spec and do some change in %description
> > 4) fedpkg commit -m "description improvement"
> > 5) fedpkg local -> produces -1.0-1.fc32
> > 6) fedpkg push -> error because build system pushed meanwhile
>
> Yes, here the packager notices something else has been going on, and he
> needs to merge or rebase. He’d have the same effect if another packager
> had been doing stuff on the package, or a mass rebuild had been going
> on. That’s the distributed decentralized aspect of git, except here the
> packager collided with himself by starting two work threads in parallel
> (one buildsys-side, one local).

The problem is that you launched some process and you need to wait
until it finishes, normally you don't need to anything like that when
working with git. The src.fp.o is a synchronization point of all
developers. Now you are adding there also a build process with which
all the developers need to synchronize. I think it is inconvenient.

>
> > 7) fedpkg pull --rebase (to quickly fix the error)
> > 8) fedpkg build -> builds -1.0-2.fc32
> >
> > To get the correct NVR for the package being built by `fedpkg local`
> > you need to wait for some external process to finish first so that you
> > can pull the new state. Only then you get correct value again.
>
> Sure, that‘s the inconvenient of state: it needs syncing. And the whole
> auto-bump thing intrinsically depends on state not provided manually by
> human beings.
>
> However putting state in git would be no better, because you’d end up
> assuming a build exists before it does, in fact, build (and builds do
> fail because packagers are imperfect humans).

The only assumption is that a certain build will produce certain NEVRA
if it succeeds.

>
> And putting state in buildsys would also not be any better because
> successful production builds end up in changelogs and you want
> changelogs to be tracked.
>
> So, no matter how you re-arange things, you’ll always have a buildsys
> sync-back somewhere (you have it today when humans change their
> changelogs after a failed build; automating that makes the sync-back
> explicit).

Scratch builds can help here a lot.

>
> >> For fedpkg verrel you'll probably want to output a last (saved in
> >> detached file) and next line (probably factorizable by externalizing
> >> the dynrel bump logic in a separate command). That’s more honest
> >> anyway, next may happen or not, when you launch fedpkg verrel, it’s
> >> mere potential (the next commit may bump version and invalidate your
> >> future build).
> >
> > There is the same problem as above with `fedpkg local`, the command
> > won't be giving you correct values at all times.
>
> There is no correct value to give before production build succeeded or
> not. When fedpkg local gives you something today it is lying (just try
> it just before someone mass rebuilds, and then try to commit after this
> mass rebuild: that will fail and you’ll have to merge/rebase).

It gives you something you can rely on if push succeeds.

>
> You’re assuming a simple universe where you’re the only one doing things
> with a package. That’s not a true assumption, many packages have shared
> ownership and maintenance (to say nothing of proven-packagers and releng
> doing things on top of them).

There is only one person doing the actual build for a given release
while multiple persons can participate in development.

>
> > It doesn't need to be the consequence of "automating changelog". It's
> > only a consequence in certain implementations. If the changelog is
> > derived purely from the git state, there aren't these problems
> > anymore.
>
> Sure there are. You're assuming anything committed to git builds before
> actually trying to build it. And expecting manual packager git fixup
> when that’s not the case. Just like in the sync-back state except with
> no tooling enforcement and help.

Who will be fixing the bugs it if not human?

> >> Putting state in detached srpm source files has the following 

[Bug 1809016] perl-Time-Out EPEL8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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



--- Comment #1 from Petr Pisar  ---
https://pagure.io/releng/fedora-scm-requests/issue/22624
https://pagure.io/releng/fedora-scm-requests/issue/22625

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

[Bug 1808730] perl-DateTime-1.52 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Fixed In Version||perl-DateTime-1.52-1.fc33
   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: Strange covert module builds [sbergmann ?]

[Michal Schorm]

> That new thing then gets leveraged into the next new thing with multiple 
> layers that would make MC Escher and Rube Goldberg proud.
Awesome :D ...

TL;DR:
I don't need to investigate it further.
I was afraid of rouge Fedora Module builds, which actually didn't happen.

If flatpack needs to rebuild everything for them again, it's a pity
(from the infrastructure load POV), but I'd guess there's no other way
currently.

Thanks for confirmation and clarification.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Mon, Mar 2, 2020 at 2:05 PM Stephen John Smoogen  wrote:
>
>
>
> On Mon, 2 Mar 2020 at 07:32, Michal Schorm  wrote:
>>
>> Can you please brief me really quick on how does the flatpack work
>> from maintainer POV? (what does it need for build / creation; what
>> does it need for runtime )
>>
>> If the flatpack uses the packages from base Fedora;
>> 'rpms/mariadb-connector-c', which I'm the maintainer of probably sent
>> me the email to notify me, that someone somewhere built the package -
>> which would be expected.
>>
>> Anyway, that doesn't clarify to me why the builds looks so much like
>> module builds.
>>
>
> The build system usually has to leverage whatever currently works and is 
> available to make whatever new thing people want to work. That new thing then 
> gets leveraged into the next new thing with multiple layers that would make 
> MC Escher and Rube Goldberg proud.
>
> I believe that Flatpacks use the container buildsystem which then relies on 
> parts of the module build system and some other items to accomplish their 
> tasks. How each of those deliver emails would depend on what tool emailed.. 
> it might be the build system itself or it could be some part of the FMN (no 
> idea what that stands for today) which saw a fedmsg which matched a filter 
> you are marked to get.
>
>
> --
> Stephen J Smoogen.
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 1808956] perl-Encode-3.03 is available

[bugzilla]

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



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

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

[Bug 1808956] perl-Encode-3.03 is available

[bugzilla]

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



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

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

[Bug 1808956] perl-Encode-3.03 is available

[bugzilla]

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



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

-- 
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: Strange covert module builds [sbergmann ?]

[Stephen John Smoogen]

On Mon, 2 Mar 2020 at 07:32, Michal Schorm  wrote:

> Can you please brief me really quick on how does the flatpack work
> from maintainer POV? (what does it need for build / creation; what
> does it need for runtime )
>
> If the flatpack uses the packages from base Fedora;
> 'rpms/mariadb-connector-c', which I'm the maintainer of probably sent
> me the email to notify me, that someone somewhere built the package -
> which would be expected.
>
> Anyway, that doesn't clarify to me why the builds looks so much like
> module builds.
>
>
The build system usually has to leverage whatever currently works and is
available to make whatever new thing people want to work. That new thing
then gets leveraged into the next new thing with multiple layers that would
make MC Escher and Rube Goldberg proud.

I believe that Flatpacks use the container buildsystem which then relies on
parts of the module build system and some other items to accomplish their
tasks. How each of those deliver emails would depend on what tool emailed..
it might be the build system itself or it could be some part of the FMN (no
idea what that stands for today) which saw a fedmsg which matched a filter
you are marked to get.


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

[Bug 1808956] perl-Encode-3.03 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Encode-3.03-442.fc33



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

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

[Bug 1808956] perl-Encode-3.03 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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



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

Orphaned packages looking for new maintainers

[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-03-02.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

aalto-xml java-sig, orphan 0 weeks ago
adns  orphan, rvokal   2 weeks ago
apache-commons-jexl   mizdebsk, orphan 2 weeks ago
appframework  orphan   2 weeks ago
argyllcms orphan, rhughes  5 weeks ago
bean-validation-api   orphan   2 weeks ago
bindexorphan   2 weeks ago
clang7.0  orphan, sergesanspaille, 3 weeks ago
  tstellar
clang8.0  orphan, sergesanspaille, 2 weeks ago
  tstellar
compress-lzf  orphan   0 weeks ago
cuneiform orphan   2 weeks ago
disruptor-thrift-server   orphan   0 weeks ago
dspam gnat, orphan 1 weeks ago
dump  jridky, orphan, vdolezal 1 weeks ago
erlang-fs orphan   1 weeks ago
felix-scr-maven-pluginjerboaa, jkang, orphan   3 weeks ago
fluxcapacitor orphan, suve 1 weeks ago
freemarkerorphan   2 weeks ago
geronimo-jta  mizdebsk, orphan 2 weeks ago
glade3dridi, kevin, nonamedotc,0 weeks ago
  orphan, rakesh
gnome-shell-extension-orphan   2 weeks ago
taskwarrior
hibernate lef, odubaj, orphan  4 weeks ago
ini4j orphan   3 weeks ago
jacocojvanek, kdaniel, lef, orphan 1 weeks ago
java-augeas   bkearney, orphan 5 weeks ago
javapoet  orphan   0 weeks ago
jboss-marshalling mizdebsk, orphan 0 weeks ago
jetty-alpn-apimizdebsk, orphan 0 weeks ago
jmol  jussilehtola, orphan 2 weeks ago
js-jquery-jstree  orphan   1 weeks ago
js-jquery-notyorphan   1 weeks ago
jspecview jussilehtola, orphan 2 weeks ago
jsr-311   mizdebsk, orphan 2 weeks ago
libdivecomputer-subsurfaceorphan, rdieter  1 weeks ago
llvm7.0   jistone, orphan, 3 weeks ago
  sergesanspaille, tstellar
llvm8.0   orphan, sergesanspaille, 2 weeks ago
  tstellar
lz4-java  orphan   0 weeks ago
lzma-java orphan   0 weeks ago
maven-jarsigner-pluginjcapik, mizdebsk, orphan 5 weeks ago
maven-shared-jarsignermizdebsk, orphan 5 weeks ago
mongo-java-driver jerboaa, lef, mskalick, orphan   1 weeks ago
naga  jussilehtola, orphan 2 weeks ago
netty mizdebsk, orphan 1 weeks ago
nimbus-jose-jwt   orphan   0 weeks ago
nodejs-grunt-wrap orphan   1 weeks ago
nodejs-typeahead.js   dcallagh, orphan, vjancik2 weeks ago
objectweb-asm3dwalluck, fnasser, mizdebsk, 0 weeks ago
   

Re: Fwd: How to update ? Was:[Red Hat Bugzilla] Your Outstanding Requests

[Petr Pisar]

On Mon, Mar 02, 2020 at 11:55:52AM +0100, J. Scheurich wrote:
> Hi,
> >> What is wrong ?
> > Bugzilla + the build system are not magically linked. You need to close the
> > bug manually after building the package in rawhide and F32.
> >
> > Just from a quick glance I think your rebuilds were successful so you can
> > close the bug report. :-)
> Thanks. But how do i close the bugreport ?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1800246
> 
> do not offer a "close bug"
> 
Write down the successfull package build (wdune-1.777-3.fc32) into "Fixed In
Version" field. Then tick on "I am providing the requested information for this
bug" item under the large comment text area. Then change a "Status" field from
NEW to CLOSED value and use NEXTRELEASE as a value of the resolution next to
it. Finally, actuate the "Save Changes" button.

-- 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: Fwd: How to update ? Was:[Red Hat Bugzilla] Your Outstanding Requests

[Ernestas Kulik]

On Mon, 2020-03-02 at 11:55 +0100, J. Scheurich wrote:
> Thanks. But how do i close the bugreport ?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1800246
> 
> do not offer a "close bug"

Change the status to CLOSED CURRENTRELEASE (and set the “Fixed In
Version” field preferrably) if it is fixed already and unset the
needinfo flag (also at the bottom).

-- 
Ernestas Kulik
Software Engineer
Base Operating Systems - Core Services - ABRT
Red Hat Czech, s.r.o.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Strange covert module builds [sbergmann ?]

[Stephan Bergmann]

On 02/03/2020 13:30, Michal Schorm wrote:

Can you please brief me really quick on how does the flatpack work
from maintainer POV? (what does it need for build / creation; what
does it need for runtime )

If the flatpack uses the packages from base Fedora;
'rpms/mariadb-connector-c', which I'm the maintainer of probably sent
me the email to notify me, that someone somewhere built the package -
which would be expected.


What should happen is that rpms/mariadb-connector-c, branch f31, is 
built in a way suitable for inclusion in the resulting LibreOffice 
flatpak.  (At runtime, that LibreOffice flatpak will run against a 
Fedora 31 flatpak runtime, but which does not include 
mariadb-connector-c used by LibreOffice, so the LibreOffice flatpak 
needs to bundle that.)



Anyway, that doesn't clarify to me why the builds looks so much like
module builds.


Presumably because the fedpkg machinery to build such flatpaks leverages 
the module-build infrastructure.

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

Re: Strange covert module builds [sbergmann ?]

[Michal Schorm]

Can you please brief me really quick on how does the flatpack work
from maintainer POV? (what does it need for build / creation; what
does it need for runtime )

If the flatpack uses the packages from base Fedora;
'rpms/mariadb-connector-c', which I'm the maintainer of probably sent
me the email to notify me, that someone somewhere built the package -
which would be expected.

Anyway, that doesn't clarify to me why the builds looks so much like
module builds.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Mon, Mar 2, 2020 at 1:23 PM Stephan Bergmann  wrote:
>
> On 02/03/2020 12:48, Michal Schorm wrote:
> > I'm the maintainer of 'mariadb' & 'mariadb-connector-c' packages
> > (rpms) and also 'modules/mariadb'.
> > Recently, I discovered a 'modules/mariadb-connector-c' exists. Created
> > by my colleague years ago, discontinued in 2017.
> > This is correct - as we don't want it to build (anymore, most likely
> > ever). There is 'mariadb-connector-c' in base Fedora (rpms namespace)
> > and it should do all the job anyone would need.
> >
> > But I got this e-mail, saying it was recently built again: [1] [2] [3] [4]
> >
> > And it is very strange:
> > 1) I don't know why I received the email (even though I'm glad I did).
> > I'm not a maintainer of the 'modules/mariadb-connector-c', nor
> > watching it (AFAIK).
> > 2) I don't understand how the most recent release of the
> > 'mariadb-connector-c' was built, since in the
> > 'modules/mariadb-connector-c' repo, there's only versions from 2017
> > and last commits 2-3 years ago; but new release (rebuild from the same
> > branch but newer (rpms/...) commit *REQUIRES* new (modules/...) commit
> > ).
> > 3) In all history of MBS [5] there are only 2 builds of
> > 'modules/mariadb-connector-c', #1462 & #1463.
> > No recent build, no nothing.
> > 3) It is tagged for the LibreOffice.
> > I'd like to know *why* anyone would like to build
> > 'mariadb-connector-c' themselves instead of using the one available.
> > 4) I tried to search for the "libreoffice" module, but haven't found any ! 
> > [6]
> >
> >
> > At this point, I have no idea what's going on.
> > The only hint is a LibreOffice *flatpack* [7]
> > which mentions 'mariadb-connector-c' [8]
> > I haven't met flatpack before, so I don't know how it works (and
> > what's it good for), but still:
> >A) I don't see the need to build the package again
> >B) I don't understand why it would disguise so much as a Fedora
> > Module. That would be really confusing and misleading, if that would
> > be the case.
> >
> >
> > The nick in Subject is the author of the KOJI build and a maintainer
> > of the 'flatpaks/libreoffice'.
> > Hope he may confirm / disprove that he's responsible for the build and
> > some rel-eng or infrastructure member would explain why it behave so
> > weird ...
>
> I assume whatever notification emails you get are a consequence of me
> doing a Flatpak-from-Fedora-RPMs build of LibreOffice (see
> ,
> ).
>
> But I have no idea how/why building that LibreOffice flatpak would
> involve builds of a discontinued modules/mariadb-connector-c, or why you
> are getting confusing email.  Maybe Owen (in cc) can shed some light on
> that?
>
> > [1] mbs/mbs.fedoraproject.org's
> > mariadb-connector-c-3.1.7-1.module_f31+8201+43134e23 completed
> > [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1470803
> > [3] mbs/mbs.fedoraproject.org's
> > mariadb-connector-c-3.1.7-1.module_f31+8207+96410d98 completed
> > [4] http://koji.fedoraproject.org/koji/buildinfo?buildID=1471050
> > [5] https://release-engineering.github.io/mbs-ui/modules
> > [6] https://src.fedoraproject.org/projects/modules/%2A
> > [7] https://src.fedoraproject.org/flatpaks/libreoffice
> > [8] 
> > https://src.fedoraproject.org/flatpaks/libreoffice/blob/master/f/libreoffice.yaml#_173
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Bug 1808816] perl-String-Print-0.94 is available

[bugzilla]

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



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

-- 
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: Strange covert module builds [sbergmann ?]

[Stephan Bergmann]

On 02/03/2020 12:48, Michal Schorm wrote:

I'm the maintainer of 'mariadb' & 'mariadb-connector-c' packages
(rpms) and also 'modules/mariadb'.
Recently, I discovered a 'modules/mariadb-connector-c' exists. Created
by my colleague years ago, discontinued in 2017.
This is correct - as we don't want it to build (anymore, most likely
ever). There is 'mariadb-connector-c' in base Fedora (rpms namespace)
and it should do all the job anyone would need.

But I got this e-mail, saying it was recently built again: [1] [2] [3] [4]

And it is very strange:
1) I don't know why I received the email (even though I'm glad I did).
I'm not a maintainer of the 'modules/mariadb-connector-c', nor
watching it (AFAIK).
2) I don't understand how the most recent release of the
'mariadb-connector-c' was built, since in the
'modules/mariadb-connector-c' repo, there's only versions from 2017
and last commits 2-3 years ago; but new release (rebuild from the same
branch but newer (rpms/...) commit *REQUIRES* new (modules/...) commit
).
3) In all history of MBS [5] there are only 2 builds of
'modules/mariadb-connector-c', #1462 & #1463.
No recent build, no nothing.
3) It is tagged for the LibreOffice.
I'd like to know *why* anyone would like to build
'mariadb-connector-c' themselves instead of using the one available.
4) I tried to search for the "libreoffice" module, but haven't found any ! [6]


At this point, I have no idea what's going on.
The only hint is a LibreOffice *flatpack* [7]
which mentions 'mariadb-connector-c' [8]
I haven't met flatpack before, so I don't know how it works (and
what's it good for), but still:
   A) I don't see the need to build the package again
   B) I don't understand why it would disguise so much as a Fedora
Module. That would be really confusing and misleading, if that would
be the case.


The nick in Subject is the author of the KOJI build and a maintainer
of the 'flatpaks/libreoffice'.
Hope he may confirm / disprove that he's responsible for the build and
some rel-eng or infrastructure member would explain why it behave so
weird ...


I assume whatever notification emails you get are a consequence of me 
doing a Flatpak-from-Fedora-RPMs build of LibreOffice (see 
, 
).


But I have no idea how/why building that LibreOffice flatpak would 
involve builds of a discontinued modules/mariadb-connector-c, or why you 
are getting confusing email.  Maybe Owen (in cc) can shed some light on 
that?



[1] mbs/mbs.fedoraproject.org's
mariadb-connector-c-3.1.7-1.module_f31+8201+43134e23 completed
[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1470803
[3] mbs/mbs.fedoraproject.org's
mariadb-connector-c-3.1.7-1.module_f31+8207+96410d98 completed
[4] http://koji.fedoraproject.org/koji/buildinfo?buildID=1471050
[5] https://release-engineering.github.io/mbs-ui/modules
[6] https://src.fedoraproject.org/projects/modules/%2A
[7] https://src.fedoraproject.org/flatpaks/libreoffice
[8] 
https://src.fedoraproject.org/flatpaks/libreoffice/blob/master/f/libreoffice.yaml#_173

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

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-String-Print-0.94-1.fc
   ||33



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

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

Today's FESCo Meeting (2020-03-02) is cancelled

[Miro Hrončok]

Due to an empty agenda today's FESCo Meeting (2020-03-02) is cancelled.

The next meeting will be on next Monday (2020-03-09), I'll chair it (I was 
supposed to chair this one).


I ask FESCo members to respond asynchronously to:

F32 incomplete Changes: https://pagure.io/fesco/issue/2349

--
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 1808774] perl-List-AllUtils-0.16 is available

[bugzilla]

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



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

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

[Bug 1808774] perl-List-AllUtils-0.16 is available

[bugzilla]

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



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

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

[Bug 1808816] perl-String-Print-0.94 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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



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

[Bug 1808774] perl-List-AllUtils-0.16 is available

[bugzilla]

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



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

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

[Bug 1808774] perl-List-AllUtils-0.16 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-List-AllUtils-0.16-1.f
   ||c33



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

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

[Bug 1808774] perl-List-AllUtils-0.16 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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



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

Strange covert module builds [sbergmann ?]

[Michal Schorm]

Hello,

I'm the maintainer of 'mariadb' & 'mariadb-connector-c' packages
(rpms) and also 'modules/mariadb'.
Recently, I discovered a 'modules/mariadb-connector-c' exists. Created
by my colleague years ago, discontinued in 2017.
This is correct - as we don't want it to build (anymore, most likely
ever). There is 'mariadb-connector-c' in base Fedora (rpms namespace)
and it should do all the job anyone would need.

But I got this e-mail, saying it was recently built again: [1] [2] [3] [4]

And it is very strange:
1) I don't know why I received the email (even though I'm glad I did).
I'm not a maintainer of the 'modules/mariadb-connector-c', nor
watching it (AFAIK).
2) I don't understand how the most recent release of the
'mariadb-connector-c' was built, since in the
'modules/mariadb-connector-c' repo, there's only versions from 2017
and last commits 2-3 years ago; but new release (rebuild from the same
branch but newer (rpms/...) commit *REQUIRES* new (modules/...) commit
).
3) In all history of MBS [5] there are only 2 builds of
'modules/mariadb-connector-c', #1462 & #1463.
   No recent build, no nothing.
3) It is tagged for the LibreOffice.
   I'd like to know *why* anyone would like to build
'mariadb-connector-c' themselves instead of using the one available.
4) I tried to search for the "libreoffice" module, but haven't found any ! [6]


At this point, I have no idea what's going on.
The only hint is a LibreOffice *flatpack* [7]
which mentions 'mariadb-connector-c' [8]
I haven't met flatpack before, so I don't know how it works (and
what's it good for), but still:
  A) I don't see the need to build the package again
  B) I don't understand why it would disguise so much as a Fedora
Module. That would be really confusing and misleading, if that would
be the case.


The nick in Subject is the author of the KOJI build and a maintainer
of the 'flatpaks/libreoffice'.
Hope he may confirm / disprove that he's responsible for the build and
some rel-eng or infrastructure member would explain why it behave so
weird ...


[1] mbs/mbs.fedoraproject.org's
mariadb-connector-c-3.1.7-1.module_f31+8201+43134e23 completed
[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=1470803
[3] mbs/mbs.fedoraproject.org's
mariadb-connector-c-3.1.7-1.module_f31+8207+96410d98 completed
[4] http://koji.fedoraproject.org/koji/buildinfo?buildID=1471050
[5] https://release-engineering.github.io/mbs-ui/modules
[6] https://src.fedoraproject.org/projects/modules/%2A
[7] https://src.fedoraproject.org/flatpaks/libreoffice
[8] 
https://src.fedoraproject.org/flatpaks/libreoffice/blob/master/f/libreoffice.yaml#_173


--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

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

Re: Ideas and proposal for removing changelog and release fields from spec file

[clime]

On Mon, 2 Mar 2020 at 11:44, Nils Philippsen  wrote:
>
> On Fri, 2020-02-28 at 15:45 +0100, clime wrote:
> > I thought the main reason not to combine update in the changelog file
> > with
> > code commits is to avoid conflicts when cherry picking as you
> > described.
> >
> > I.e. i do minor update specifically in f32 and generate changelog
> > file
> > in the same commit.
> > Then I want to do normal release update for all fedora branches. I
> > start with master (as usual)
> > and add e.g. add a new patch and generate the changelog file because
> > i
> > would like to add more info, then commit.
> > Now I cannot cherry-pick that commit into f32 without conflict.
> >
> > In this case we wouldn't achieve one the targets of this proposal
> > (afaik) => getting rid of merge conflicts in changelog and release -
> > this is cherry-picking but still it would be nice not to have
> > conflicts there.
> > This target isn't in the document i think but i thought this is one
> > of
> > the goals.
>
> Leaving aside the advantages or disadvantages of a detached changelog
> (vs. in-spec vs. "everything from the commits"), our aim is to reduce
> the potential for conflicts between concurrent PRs or when cherry-
> picking between branches. If what we end up with can't avoid them
> completely for (what should be) corner cases, like when you have to
> manually fuzz with the generated changelog, that may not be ideal, but
> it's still a considerable improvement over the present situation.

Right, but if we can eliminate the problem completely why not do it?

clime

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

[Neal Gompa]

On Mon, Mar 2, 2020 at 5:47 AM Igor Gnatenko  wrote:
>
> Hey folks,
>
> We recently started to use Ansible more and we are using some ansible
> collection which is not compatible with Python 2.
>
> Are there any plans to switch Ansible to Python 3 in EPEL7 or are
> there any recommendations what to do in such cases as we have?

I suspect both versions would need to be shipped in EPEL7 unless
upstream Ansible just switches to Python 3 for EL7 too.



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

Re: Creation of pkgconfig file for libraries that do not ship one

[Daniel P . Berrangé]

On Mon, Mar 02, 2020 at 12:03:01PM +0100, Guido Aulisi wrote:
> Hi,
> can we create a pkgconfig file for libraries that do not ship one?
> I did not find anything about that in our packaging policy.
> 
> A bug was filed [0] about a missing pkgconfig file for zita-convolver
> library and I'm thinking og creating the missing pkgconfig file
> myself.

I can certainly understand the desire to have a pkgconfig file for every
library that exists. With my app developer hat though on I'd encourage you
*not* to add this in downstream Fedora packaging, as this effectively
forks the project from the POV.  Any application which depends on use of
the pkg-config file will now only build in Fedora, or other distros which
have also added the non-upstream pkg-config file. If they keep fallback
logic for the non-pkg-config case, this makes their life even harder as
now they have 2 ways to detect dependancies to maintain & hope they both
have the same semantics.

Thus I'd encourage you to take the request for a pkg-config file straight
to the upstream project. Most projects are receptive to this kind of thing,
especially if you're providing the patch.

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

Re: Creation of pkgconfig file for libraries that do not ship one

[Neal Gompa]

On Mon, Mar 2, 2020 at 6:03 AM Guido Aulisi  wrote:
>
> Hi,
> can we create a pkgconfig file for libraries that do not ship one?
> I did not find anything about that in our packaging policy.
>
> A bug was filed [0] about a missing pkgconfig file for zita-convolver
> library and I'm thinking og creating the missing pkgconfig file
> myself.
>
> Thank you
> Guido
>
> FAS: tartina
>
> [0]: https://bugzilla.redhat.com/show_bug.cgi?id=1809043

In general, if you want to do this, you should contribute it upstream.
Those files are only useful if people can actually use them, and
generally they are only used if upstream has them.



-- 
真実はいつも一つ！/ 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: Ideas and proposal for removing changelog and release fields from spec file

[Nicolas Mailhot via devel]

Le 2020-03-01 02:31, clime a écrit :

On Sat, 29 Feb 2020 at 21:50, Nicolas Mailhot via devel
 wrote:


Le samedi 29 février 2020 à 20:30 +0100, clime a écrit :



Putting %{dynrel} reconciliation in the rpmbuild -bs stage using
detached file state means that fedpkg local (or checking out git state
and building in mock or copr or OBS or via plain rpmbuild -bs) will
give you the same result as launching fedpkg build.


Well, I believe it doesn't. You run:

1) fedpkg local -> produces -1.0-1.fc32 (1 in release because
you haven't built that package before)
2) fedpkg build


At that point state is undefined till the build succeeds or not. If the 
build succeeds, the buildsystem will write back a new state. Let’s 
assume it succeeds.



3) vim .spec and do some change in %description
4) fedpkg commit -m "description improvement"
5) fedpkg local -> produces -1.0-1.fc32
6) fedpkg push -> error because build system pushed meanwhile


Yes, here the packager notices something else has been going on, and he 
needs to merge or rebase. He’d have the same effect if another packager 
had been doing stuff on the package, or a mass rebuild had been going 
on. That’s the distributed decentralized aspect of git, except here the 
packager collided with himself by starting two work threads in parallel 
(one buildsys-side, one local).



7) fedpkg pull --rebase (to quickly fix the error)
8) fedpkg build -> builds -1.0-2.fc32

To get the correct NVR for the package being built by `fedpkg local`
you need to wait for some external process to finish first so that you
can pull the new state. Only then you get correct value again.


Sure, that‘s the inconvenient of state: it needs syncing. And the whole 
auto-bump thing intrinsically depends on state not provided manually by 
human beings.


However putting state in git would be no better, because you’d end up 
assuming a build exists before it does, in fact, build (and builds do 
fail because packagers are imperfect humans).


And putting state in buildsys would also not be any better because 
successful production builds end up in changelogs and you want 
changelogs to be tracked.


So, no matter how you re-arange things, you’ll always have a buildsys 
sync-back somewhere (you have it today when humans change their 
changelogs after a failed build; automating that makes the sync-back 
explicit).



For fedpkg verrel you'll probably want to output a last (saved in
detached file) and next line (probably factorizable by externalizing
the dynrel bump logic in a separate command). That’s more honest
anyway, next may happen or not, when you launch fedpkg verrel, it’s
mere potential (the next commit may bump version and invalidate your
future build).


There is the same problem as above with `fedpkg local`, the command
won't be giving you correct values at all times.


There is no correct value to give before production build succeeded or 
not. When fedpkg local gives you something today it is lying (just try 
it just before someone mass rebuilds, and then try to commit after this 
mass rebuild: that will fail and you’ll have to merge/rebase).


You’re assuming a simple universe where you’re the only one doing things 
with a package. That’s not a true assumption, many packages have shared 
ownership and maintenance (to say nothing of proven-packagers and releng 
doing things on top of them).



It doesn't need to be the consequence of "automating changelog". It's
only a consequence in certain implementations. If the changelog is
derived purely from the git state, there aren't these problems
anymore.


Sure there are. You're assuming anything committed to git builds before 
actually trying to build it. And expecting manual packager git fixup 
when that’s not the case. Just like in the sync-back state except with 
no tooling enforcement and help.

Putting state in detached srpm source files has the following super-
duper property. You can import the srpm or scm checkout between
systems, and they’ll just pick up from the point the previous system
left things, without needing a full scm import.


That's nice if there is always just a single provider of the given
package in our ecosystem. In case of copr, you can fork a certain repo
and continue building there so you will be getting bumped numbers on
top of the work done in the original repo. But once the original repo
starts producing some builds as well you will be getting that package
in two versions in two different coprs and while the original repo
might have done less builds than the forked one since the fork
happened, it can contain the package with more features because the
forked repo was simply playing around.


You will never get official Fedora git releases changed based on the 
status of some copr builds. That takes a deliberate package admin action 
(and that works in the proposal, just fedpkg import the last srpm built 
in copr, that syncs repos).


If you want things to work on the other direction, copr will need to 
read 

Creation of pkgconfig file for libraries that do not ship one

[Guido Aulisi]

Hi,
can we create a pkgconfig file for libraries that do not ship one?
I did not find anything about that in our packaging policy.

A bug was filed [0] about a missing pkgconfig file for zita-convolver
library and I'm thinking og creating the missing pkgconfig file
myself.

Thank you
Guido

FAS: tartina

[0]: https://bugzilla.redhat.com/show_bug.cgi?id=1809043
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Fwd: How to update ? Was:[Red Hat Bugzilla] Your Outstanding Requests

[J. Scheurich]

Hi,
>> What is wrong ?
> Bugzilla + the build system are not magically linked. You need to close the
> bug manually after building the package in rawhide and F32.
>
> Just from a quick glance I think your rebuilds were successful so you can
> close the bug report. :-)
Thanks. But how do i close the bugreport ?

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

do not offer a "close bug"

so long
MUFTI
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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] Ansible & Python 3 in EPEL7

[Igor Gnatenko]

Hey folks,

We recently started to use Ansible more and we are using some ansible
collection which is not compatible with Python 2.

Are there any plans to switch Ansible to Python 3 in EPEL7 or are
there any recommendations what to do in such cases as we have?
-- 
-Igor Gnatenko
___
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: Ideas and proposal for removing changelog and release fields from spec file

[Nils Philippsen]

On Fri, 2020-02-28 at 15:45 +0100, clime wrote:
> I thought the main reason not to combine update in the changelog file
> with
> code commits is to avoid conflicts when cherry picking as you
> described.
> 
> I.e. i do minor update specifically in f32 and generate changelog
> file
> in the same commit.
> Then I want to do normal release update for all fedora branches. I
> start with master (as usual)
> and add e.g. add a new patch and generate the changelog file because
> i
> would like to add more info, then commit.
> Now I cannot cherry-pick that commit into f32 without conflict.
> 
> In this case we wouldn't achieve one the targets of this proposal
> (afaik) => getting rid of merge conflicts in changelog and release -
> this is cherry-picking but still it would be nice not to have
> conflicts there.
> This target isn't in the document i think but i thought this is one
> of
> the goals.

Leaving aside the advantages or disadvantages of a detached changelog
(vs. in-spec vs. "everything from the commits"), our aim is to reduce
the potential for conflicts between concurrent PRs or when cherry-
picking between branches. If what we end up with can't avoid them
completely for (what should be) corner cases, like when you have to
manually fuzz with the generated changelog, that may not be ideal, but
it's still a considerable improvement over the present situation.

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