date:20200404

On Sat, Apr 4, 2020 at 8:31 PM Miro Hrončok  wrote:
>
> To clarify: In Fedora Core/Extras the separation was by access permissions. 
> Here
> it is based on knowledge and interests (or a lack thereof). People with zero
> knowledge and interest in "RHEL next" development will not be able to 
> contribute
> to Fedora packages (as easy as before) because the sources are no longer only
> meant for Fedora.
>

It's a bit of a divergence, but...

From my foggy memories of my early days in Fedora (I started in the
Fedora Project as a contributor officially in November 2007, but I had
been lurking and poking around for two years prior), the Core/Extras
split was slightly more complicated than that. It was true that were
was an ACL split, but there was also a CVS tree split and the Fedora
"Core" was maintained within the Red Hat Dist-CVS (though nobody
called it that back then!) and synced out to the public CVS tree for
Fedora Core. The transition to the merged CVS tree involved a lot of
complicated work from a lot of different people, and ultimately
enabled discontinuing the weird setup for Core with Fedora 7 and
transitioning to the Koji build system and Bodhi update system, which
we still use today. The transition to Dist-Git in 2009 would have been
ridiculously more difficult if that hadn't happened already.

In case anyone wants to take a trip down memory lane:
https://fedoraproject.org/wiki/Infrastructure/CoreExtrasMerge

-- 
真実はいつも一つ！/ 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 1817797] perl-App-cpm-0.990 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2020-04-05 00:15:38



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-2b35f0ffcf has been pushed to the Fedora 32 stable repository.
If problem still persists, 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

Re: Qt 5.14.2 coming to rawhide

2020-04-04 Thread Rex Dieter

Richard Shaw wrote:

> On Sat, Apr 4, 2020 at 6:50 PM Rex Dieter  wrote:
> 
>> Richard Shaw wrote:
>>
>> > On Sat, Apr 4, 2020 at 5:58 PM Rex Dieter  wrote:
>> >
>> >> FYI, Started work on importing Qt 5.14.2 into rawhide today, with
>> >> work-in- progress being done in side tag f33-build-side-21031
>> >>
>> >> I figure it'll take at least a few days to get the core bits and all
>> >> dependencies rebuilt.  Will provide status updates as warranted.
>>
>> > Looking at the changelog, do I need to drop python-pyside2's BR
>> > on qt5-qtwebkit-devel?
>>
>> I don't know much about pyside, sorry.  I don't know.
>>
> 
> Sorry, I should have been more specific, I was referring to this:
> 
> * Sat Apr 04 2020 Rex Dieter  - 5.14.2-1 -
> 5.14.2
> - drop qt5-qtwebkit from metapackage (hasn't been a core qt5 pkg for
> awhile)

That only affects the 'qt5' and 'qt5-devel' metapackages, which no real 
package in fedora should be using anyway.  Not relevant to anything else 
(including pyside).

-- Rex

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

On 02. 04. 20 20:07, Stephen Gallagher wrote:

On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok wrote:

The change proposal received overly negative feedback by the packager community
as represented both by RHEL¹ and non-RHEL maintainers. Despite being reworked
several times, none of this feedback was reflected in the proposal, only new
reasons why this is going to be done the original way were added. It seems that
feedback is collected not to find the best technical solution, but rather to
find ways to justify a solution that's already decided.

This is needlessly antagonistic, Miro. We've collected the feedback in
good faith, examined it and then identified shortcomings with it. For
the sake of clarity in the Change Proposal, I've recorded that
reasoning there.

This is how I saw your responses to the received feedback. I now see that for
you, this is "identifying shortcomings", however for me and others I've talked
to and who also participate in this thread, this seemed like a solution has
already been decided and our feedback is being rejected. As a change owner, you
have every right to do that, but as long as I don't follow or agree with your
rationale for this, I'll vote -1. (And as a side note, that might be completely
fine at the end, if you get a majority despite that.)

Either way, sorry for being antagonistic. I always do my best to disagree
respectfully. I guess I'll try harder next time.

Key questions in the *Detailed Description* remain "out of scope of ELN" or not
answered clearly.

If something is not clear, please constructively offer that
information. I've been doing my best to rephrase and clarify anything
that has come up. Anything remaining that is "out of scope of ELN" is
literally just that. ELN's scope is largely "Make Fedora Rawhide more
useful to downstream so that downstream developers will work there
instead of internally".

Others are already reporting back in this thread on what's not clear to them.
I've also included some of those in my reply to Aleksandra's response to my vote.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SFTKW7ZC2WVA22HKLHOA5ZZHVPPU6XTB/

While benefiting the entire Fedora/RHEL/CentOS/EPEL ecosystem is certainly a
good goal, I believe that doing this in a way that alienates a significant part
of our packagers is a disservice to Fedora. The concerned packagers believe that
Fedora is (and should remain) the upstream for RHEL, not RHEL itself. This might
be shifting us to the undesirable mindset that Fedora is only a test bed for
RHEL or a RHEL alpha version.

I think you're missing a major point here. The purpose of ELN is for
*that* to be the RHEL test-bed/Alpha. But we want it to stay as close
as possible to Fedora Rawhide because that is how we solve two
problems: 1) lack of consistent involvement by Red Hat engineers in
Fedora and 2) eliminate the long lag-time between when features land
in Fedora and when someone evaluates them for RHEL.

The purpose of ELN is to be RHEL test-bed/Alpha? I am genuinely lost in all the
stated purposes and goals of ELN (as also said in the e-mail linked above).

Either way, If we want:

a) ELN to be built from Fedora sources and stay as close as possible to it
b) ELN to be RHEL test-bed/Alpha
c) Fedora not to be RHEL test-bed/Alpha

Aren't those contradicting things? What major point I am missing here?

For me this feels like a step back to the [discontinued Fedora
Core](https://www.redhat.com/archives/fedora-devel-list/2007-January/msg00091.html),
where the packages that were included in RHEL could only be maintained by their
RHEL maintainers. Fedora relies on the contributions of non-RHEL developers —
and those often have little interest in downstream work. If we alienate the
community contributors, it will ultimately lead to a worse RHEL down the road.

I have no idea where you're getting this from, as we've tried to be
very clear from the start that we want to make the pipeline of Fedora
-> RHEL much more clear. We're not changing access permissions on
these repositories. We're going to be opening up some of the "secret
sauce" so that more of the community can see what we are testing. They
will have greater insight into the potential usage of their packages.

To clarify: In Fedora Core/Extras the separation was by access permissions. Here
it is based on knowledge and interests (or a lack thereof). People with zero
knowledge and interest in "RHEL next" development will not be able to contribute
to Fedora packages (as easy as before) because the sources are no longer only
meant for Fedora.

For the stated reasons I am *-1 for this change in its current form*.

That is your privilege as a member of FESCo. As I've said, however, I
think you've misunderstood the situation.

Do you want to leave it at "this is your privilege" or would you rather try to
lower the level misunderstanding? In other words, do you think it is still worth
it to have this

Re: Qt 5.14.2 coming to rawhide

On Sat, Apr 4, 2020 at 6:50 PM Rex Dieter  wrote:

> Richard Shaw wrote:
>
> > On Sat, Apr 4, 2020 at 5:58 PM Rex Dieter  wrote:
> >
> >> FYI, Started work on importing Qt 5.14.2 into rawhide today, with
> >> work-in- progress being done in side tag f33-build-side-21031
> >>
> >> I figure it'll take at least a few days to get the core bits and all
> >> dependencies rebuilt.  Will provide status updates as warranted.
>
> > Looking at the changelog, do I need to drop python-pyside2's BR
> > on qt5-qtwebkit-devel?
>
> I don't know much about pyside, sorry.  I don't know.
>

Sorry, I should have been more specific, I was referring to this:

* Sat Apr 04 2020 Rex Dieter  - 5.14.2-1 -
5.14.2
- drop qt5-qtwebkit from metapackage (hasn't been a core qt5 pkg for awhile)

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

Re: Qt 5.14.2 coming to rawhide

2020-04-04 Thread Rex Dieter

Richard Shaw wrote:

> On Sat, Apr 4, 2020 at 5:58 PM Rex Dieter  wrote:
> 
>> FYI, Started work on importing Qt 5.14.2 into rawhide today, with
>> work-in- progress being done in side tag f33-build-side-21031
>>
>> I figure it'll take at least a few days to get the core bits and all
>> dependencies rebuilt.  Will provide status updates as warranted.

> Looking at the changelog, do I need to drop python-pyside2's BR
> on qt5-qtwebkit-devel?

I don't know much about pyside, sorry.  I don't know.

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3


On 02. 04. 20 19:21, Aleksandra Fedorova wrote:

While benefiting the entire Fedora/RHEL/CentOS/EPEL ecosystem is certainly a
good goal, I believe that doing this in a way that alienates a significant part
of our packagers is a disservice to Fedora. The concerned packagers believe that
Fedora is (and should remain) the upstream for RHEL, not RHEL itself. This might
be shifting us to the undesirable mindset that Fedora is only a test bed for
RHEL or a RHEL alpha version.

I literally addressed this part three times already here on the
mailing list. And three times I got ignored, with someone posting the
same concern again.
If you'd like to have a conversation, please listen to the replies you get.


Hi Aleksandra, sorry for the late reply, I needed to take a break from this.

I am trying very hard to listen and to follow the entire thread. Forgive me if 
I've missed some replies or if I don't understand some properly. My vote is 
based on the change proposal as written. Could you please also address this in 
the proposal?



I'll reiterate again:

ELN is a tool to develop Fedora. Conditionals for ELN packages are
going to be applied in those places where it makes sense and where it
is approved by the Fedora packager.


The change proposal literally says that if a package fails to build in ELN, 
conditionals will be updated via a pull request that states a time limit. That 
does not imply approval.



Yes, we believe that adding the flexibility in Fedora deptrees and
feature choices is beneficial to Fedora. It is Fedora flexibility,
which can then be used by downstream, whatever the downstream would
be. We are not going to enforce this vision, but we'd like to work
with people who share it, to test if this can actually work.


I am all for flexibility. I am all for e.g. adding bconds to enable/disable 
certain things in Fedora instead of patching it out in downstreams.


However I believe that adding "if rhel, use prebuilt docs" is not adding any 
flexibility, it adds a layer of downstream specific "hacks" to our specs.


IIRC it was you, who used an upstream-downstream analogy between a software 
project packaged in Fedora and Fedora and between Fedora and ELN/RHEL/EL. Sorry 
if it was somebody else participating in this discussion.
I will try to use that analogy here: We do not send patches to CPython that add 
"%ifdef FEDORA, use /usr/lib64" into their source files. That does not add 
flexibility. We send patches to CPython that add the "--withplatlib" option that 
we set in our specs to /usr/lib64.


The change proposal literally says that if I do not want to have %if's in my 
spec files the ELN SIG may provide a PR as described above or will discuss 
alternative approaches on an individual basis with me.


That is very vague. What's going to be in the PR if not conditionals? What are 
the alternate approaches for packagers who don't share this vision? It was 
repeatedly said in the recent e-mails here that ELN might fallback to regular 
rawhide builds in that case. Can this be documented in the proposal please?


You seem to describe this as "some packages are maintained by packagers who 
share the ELN vision and others be packagers who don't, so we'll work with the 
ones who do". But in my opinion, it is not that simple. One of my concern is 
drive-by contributors. What if the Fedora maintainer shares the ELN vision, but 
the drive-by contributor doesn't know anything about the ELN differences and 
they just want to provide some Fedora enhancement or bugfix, and it breaks the 
ELN build? Should such otherwise valuable contribution be rejected because they 
don't share the vision and this particular package is part of the "ELN-friendly 
set"?



We discard branching as the part of the ELN proposal, exactly because
of the concern that Fedora infrastructure is going to be used by
downstream maintainers to develop downstream packages. We DO NOT want
that. That's why we say: if Fedora packager and downstream can not
come up with the common solution on how to incorporate downstream
changes in Fedora Rawhide, then downstream work can not and should not
happen in Fedora (and as ELN is Fedora, it should not happen in ELN
either).


From what part of the proposal do I deduce this particular approach? Is this 
your personal approach you will persuit as a member of the ELN SIG or something 
that's worth describing in the proposal?



Branching and dist git sync to downstream can and will happen, but on
downstream terms and on downstream infrastructure. This work doesn't
belong to Fedora, and therefore doesn't need to be discussed here in
this change proposal.


That's fair.


Now you blame us for thing which we haven't proposed.


I am not blaming anyone for anything. I am providing my feedback and opinions on 
a change proposal as well as summarizing feedback by others. Can we please take 
a step back and not assume blaming? If my language implied blaming, it was not 
intended.



And it is hard to have a

Re: Qt 5.14.2 coming to rawhide

On Sat, Apr 4, 2020 at 5:58 PM Rex Dieter  wrote:

> FYI, Started work on importing Qt 5.14.2 into rawhide today, with work-in-
> progress being done in side tag f33-build-side-21031
>
> I figure it'll take at least a few days to get the core bits and all
> dependencies rebuilt.  Will provide status updates as warranted.
>

Looking at the changelog, do I need to drop python-pyside2's BR
on qt5-qtwebkit-devel?

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

Qt 5.14.2 coming to rawhide

2020-04-04 Thread Rex Dieter

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

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

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

Re: CPE Weekly: 2020-04-04

2020-04-04 Thread clime

On Sat, 4 Apr 2020 at 23:56, Chris Murphy  wrote:
>
> On Sat, Apr 4, 2020 at 2:36 PM Randy Barlow
>  wrote:
> >
> > On 4/4/20 3:02 PM, Aoife Moloney wrote:
> > > However we do
> > > recognize that it was still nonetheless a decision that was not made
> > > in public, and for that we can only now offer our apologies for this
> > > mistake and learn a hard lesson from it.
> >
> > It's simply not true that this is the only thing that can be done. You
> > can hold off on making a decision, and follow an open process instead.
> >
> > > We do want to let you know that we deeply appreciate the requirements
> > > you have given us and would like to ask you to continue engaging with
> > > us while we are moving through our next steps with GitLab.
> >
> > What would be the goal if the community were to continue to engage with
> > CPE management when it has demonstrated that it does not meaningfully
> > engage with the community?
>
> I agree. Treating this as a fait accompli is not a good idea.
>
> There's been a trust reducing event. Repairing the damage should
> happen before further actions requiring trust are taken.
>
> Flaws have been discovered in the process used to arrive at the
> decision, and therefore it's not clear whether the decision is valid.
> The mistake has been admitted, and treating it as moot suggests in
> fact nothing has been learned from the mistake.

I agree with this as well.

clime

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

Re: CPE Weekly: 2020-04-04

2020-04-04 Thread Chris Murphy

On Sat, Apr 4, 2020 at 2:36 PM Randy Barlow
 wrote:
>
> On 4/4/20 3:02 PM, Aoife Moloney wrote:
> > However we do
> > recognize that it was still nonetheless a decision that was not made
> > in public, and for that we can only now offer our apologies for this
> > mistake and learn a hard lesson from it.
>
> It's simply not true that this is the only thing that can be done. You
> can hold off on making a decision, and follow an open process instead.
>
> > We do want to let you know that we deeply appreciate the requirements
> > you have given us and would like to ask you to continue engaging with
> > us while we are moving through our next steps with GitLab.
>
> What would be the goal if the community were to continue to engage with
> CPE management when it has demonstrated that it does not meaningfully
> engage with the community?

I agree. Treating this as a fait accompli is not a good idea.

There's been a trust reducing event. Repairing the damage should
happen before further actions requiring trust are taken.

Flaws have been discovered in the process used to arrive at the
decision, and therefore it's not clear whether the decision is valid.
The mistake has been admitted, and treating it as moot suggests in
fact nothing has been learned from the mistake.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F32: System hangs when using mock

2020-04-04 Thread Artem Tim

https://bugzilla.redhat.com/show_bug.cgi?id=1754807
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F32: System hangs when using mock

2020-04-04 Thread Chris Murphy

On Sat, Apr 4, 2020 at 3:13 PM Ankur Sinha  wrote:
>
> Hello,
>
> I've had my system hang up a few times when running mock this evening.
> I've got to power it off and restart it using the switch. Is anyone else
> seeing this?

After the hang, are you able to switch to a vt or login remotely via ssh?

If not, two options for getting more information: remotely login via
ssh, and use 'journalctl -fk' to follow kernel messages as they
happen; it might get out by sshd before it gets committed to disk.
More likely successful is switching to a vt, and running mock there,
and seeing if you get a stack trace. Capture with a cell phone.
*shrug*

What's the exact command? I might try to reproduce if I get a moment,
I have those same versions.

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

Review request: perl-Array-IntSpan

2020-04-04 Thread Sandro Mani


Hi

The licensecheck saga continues, I managed to get hold of the upstream 
perl-Array-IntSpan maintainer to re-license it to a Fedora permissible 
license, so I've reopened the review request [1]. Reposting review 
request since jplesnik seems not to be available at the moment.


Happy to review in exchange.

Thanks
Sandro

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1797301
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

F32: System hangs when using mock

2020-04-04 Thread Ankur Sinha

Hello,

I've had my system hang up a few times when running mock this evening.
I've got to power it off and restart it using the switch. Is anyone else
seeing this?

$ rpm -q systemd mock
systemd-245.4-1.fc32.x86_64
mock-2.2-1.fc32.noarch

$ uname -r
5.6.2-300.fc32.x86_64

This is all I found in the journal. Any ideas?

Apr 04 22:03:36 ankur userhelper[28439]: running '/usr/libexec/mock/mock -r 
fedora-rawhide-x86_64 rebuild ./steps-3.5.0-1.fc32.src.rpm' with root 
privileges on behalf of 'asinha'
Apr 04 22:03:38 ankur systemd[1071]: Starting Tracker metadata database store 
and lookup manager...
Apr 04 22:03:38 ankur systemd[1071]: Started Tracker metadata database store 
and lookup manager.
Apr 04 22:03:40 ankur systemd-machined[786]: New machine 
661c10ac41c549e9a064fe8e9cac3dbe.
Apr 04 22:03:40 ankur audit: BPF prog-id=99 op=LOAD
Apr 04 22:03:40 ankur systemd[1]: Started Container 
661c10ac41c549e9a064fe8e9cac3dbe.
Apr 04 22:03:40 ankur systemd[1]: 
machine-661c10ac41c549e9a064fe8e9cac3dbe.scope: Succeeded.
Apr 04 22:03:40 ankur systemd-machined[786]: Machine 
661c10ac41c549e9a064fe8e9cac3dbe terminated.
Apr 04 22:03:40 ankur audit: BPF prog-id=99 op=UNLOAD
Apr 04 22:03:40 ankur systemd-machined[786]: New machine 
9ccd5c6b58ab49de84e726e5d651e895.
Apr 04 22:03:40 ankur audit: BPF prog-id=100 op=LOAD
Apr 04 22:03:40 ankur systemd[1]: Started Container 
9ccd5c6b58ab49de84e726e5d651e895.
Apr 04 22:03:41 ankur systemd[1]: 
machine-9ccd5c6b58ab49de84e726e5d651e895.scope: Succeeded.
Apr 04 22:03:41 ankur systemd-machined[786]: Machine 
9ccd5c6b58ab49de84e726e5d651e895 terminated.
Apr 04 22:03:41 ankur audit: BPF prog-id=100 op=UNLOAD
Apr 04 22:03:41 ankur systemd-machined[786]: New machine 
e1c44a4151034f3c8b0afa982fd3418f.
Apr 04 22:03:41 ankur audit: BPF prog-id=101 op=LOAD
Apr 04 22:03:41 ankur systemd[1]: Started Container 
e1c44a4151034f3c8b0afa982fd3418f.
Apr 04 22:03:41 ankur systemd[1]: 
machine-e1c44a4151034f3c8b0afa982fd3418f.scope: Succeeded.
Apr 04 22:03:41 ankur systemd-machined[786]: Machine 
e1c44a4151034f3c8b0afa982fd3418f terminated.
Apr 04 22:03:41 ankur audit: BPF prog-id=101 op=UNLOAD
Apr 04 22:03:41 ankur systemd-machined[786]: New machine 
2fd8e69cb3aa421786a30a58c5666afe.
Apr 04 22:03:41 ankur audit: BPF prog-id=102 op=LOAD
Apr 04 22:03:41 ankur systemd[1]: Started Container 
2fd8e69cb3aa421786a30a58c5666afe.
Apr 04 22:03:41 ankur systemd[1]: 
machine-2fd8e69cb3aa421786a30a58c5666afe.scope: Succeeded.
Apr 04 22:03:41 ankur systemd-machined[786]: Machine 
2fd8e69cb3aa421786a30a58c5666afe terminated.
Apr 04 22:03:41 ankur audit: BPF prog-id=102 op=UNLOAD
Apr 04 22:03:42 ankur systemd-machined[786]: New machine 
87d23d4848bc4ea8bd4a08d14c8cd273.
Apr 04 22:03:42 ankur audit: BPF prog-id=103 op=LOAD
Apr 04 22:03:42 ankur systemd[1]: Started Container 
87d23d4848bc4ea8bd4a08d14c8cd273.
Apr 04 22:03:44 ankur systemd[1]: 
machine-87d23d4848bc4ea8bd4a08d14c8cd273.scope: Succeeded.
Apr 04 22:03:44 ankur systemd-machined[786]: Machine 
87d23d4848bc4ea8bd4a08d14c8cd273 terminated.
Apr 04 22:03:44 ankur systemd[1]: 
machine-87d23d4848bc4ea8bd4a08d14c8cd273.scope: Consumed 1.491s CPU time.
Apr 04 22:03:44 ankur audit: BPF prog-id=103 op=UNLOAD
Apr 04 22:03:44 ankur systemd[1071]: 
var-lib-mock-fedora\x2drawhide\x2dx86_64-root-dev-pts.mount: Succeeded.
Apr 04 22:03:44 ankur systemd[1071]: 
var-lib-mock-fedora\x2drawhide\x2dx86_64-root-dev-shm.mount: Succeeded.
Apr 04 22:03:44 ankur systemd[1]: 
var-lib-mock-fedora\x2drawhide\x2dx86_64-root-dev-pts.mount: Succeeded.
Apr 04 22:03:44 ankur systemd[1]: 
var-lib-mock-fedora\x2drawhide\x2dx86_64-root-dev-shm.mount: Succeeded.
Apr 04 22:03:44 ankur systemd[1071]: 
var-lib-mock-fedora\x2drawhide\x2dx86_64-root-sys.mount: Succeeded.
Apr 04 22:03:44 ankur systemd[1]: 
var-lib-mock-fedora\x2drawhide\x2dx86_64-root-sys.mount: Succeeded.
Apr 04 22:03:44 ankur systemd[1071]: 
var-lib-mock-fedora\x2drawhide\x2dx86_64-root-proc.mount: Succeeded.
Apr 04 22:03:44 ankur systemd[1]: 
var-lib-mock-fedora\x2drawhide\x2dx86_64-root-proc.mount: Succeeded.
Apr 04 22:03:44 ankur systemd-machined[786]: New machine 
8e61483fc8194441bc938f807f64196f.
Apr 04 22:03:44 ankur audit: BPF prog-id=104 op=LOAD
Apr 04 22:03:44 ankur systemd[1]: Started Container 
8e61483fc8194441bc938f807f64196f.
Apr 04 22:03:44 ankur systemd[1]: 
machine-8e61483fc8194441bc938f807f64196f.scope: Succeeded.
Apr 04 22:03:44 ankur systemd-machined[786]: Machine 
8e61483fc8194441bc938f807f64196f terminated.
Apr 04 22:03:44 ankur audit: BPF prog-id=104 op=UNLOAD
Apr 04 22:03:44 ankur systemd-machined[786]: New machine 
ff052ace0b8d48c8baf135434a7dc259.
Apr 04 22:03:44 ankur audit: BPF prog-id=105 op=LOAD
Apr 04 22:03:44 ankur systemd[1]: Started Container 
ff052ace0b8d48c8baf135434a7dc259.
Apr 04 22:03:45 ankur systemd[1]: 
machine-ff052ace0b8d48c8baf135434a7dc259.scope: Succeeded.
Apr 04 22:03:45 ankur systemd-machined[786]: Machine 
ff052ace0b8d48c8baf135434a7dc259 terminated.
Apr 04 22:03:45 ankur audit:

Re: Replace buildroot overrides with user side tags?

On Sat, Apr 4, 2020 at 3:52 PM Neal Gompa  wrote:

> On Sat, Apr 4, 2020 at 4:50 PM Richard Shaw  wrote:
> >
> > To be clear, I've only used them for rawhide, but can they be used in
> other branches?
> >
>
> As of last Monday, yes. There are still some quirks to iron out, though...
>

Awesome! Not only are they easier to use but being able to choose the side
tag in the Bodhi web interface makes pushing the updates painless!

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

Re: Replace buildroot overrides with user side tags?

On Sat, Apr 4, 2020 at 4:50 PM Richard Shaw  wrote:
>
> To be clear, I've only used them for rawhide, but can they be used in other 
> branches?
>

As of last Monday, yes. There are still some quirks to iron out, though...



-- 
真実はいつも一つ！/ 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: Replace buildroot overrides with user side tags?

To be clear, I've only used them for rawhide, but can they be used in other
branches?

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

Re: Replace buildroot overrides with user side tags?

2020-04-04 Thread Kevin Fenzi

On Sat, Apr 04, 2020 at 02:30:41PM -0500, Richard Shaw wrote:
> Also, it doesn't take NEAR as long for the package to be available in a
> side tag then a buildroot override...
> 
> Been waiting almost an hour for one in f32...

This is due to kojira (the koji process that handles making new repos)
not working as expected. 

https://pagure.io/koji/issue/2119 is the upstream issue where we are
trying to sort it out. 

kevin


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

Re: Replace buildroot overrides with user side tags?

2020-04-04 Thread Kevin Fenzi

On Sat, Apr 04, 2020 at 09:22:29AM -0400, Neal Gompa wrote:
> On Sat, Apr 4, 2020 at 8:57 AM Richard Shaw  wrote:
> >
> > Perhaps this has been discussed already but I found the new user side tags 
> > a much easier process than using buildroot overrides.
> >
> > Is the only *effective* difference that with a buildroot override that 
> > *everyone* can use it (on purpose or not) and with side tags only the 
> > creator (or users shared to) can use the package?
> >
> > Just to simply things I would be in favor of using side tags across the 
> > board and dropping buildroot overrides but there's probably some situations 
> > I'm not thinking of.
> >
> 
> That is pretty much the only difference. That said, anyone can build
> in a particular side tag once it's created, so I think this matters a
> lot less than people would think.
> 
> I think once the side tag update workflow becomes more performant and
> reliable, we probably could eliminate the usage of overrides.

+1. There still seems to be a few issues with side tags, but once they
are all sorted I think this is a great idea. 

kevin


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

Re: CPE Weekly: 2020-04-04

2020-04-04 Thread Randy Barlow


On 4/4/20 3:02 PM, Aoife Moloney wrote:

However we do
recognize that it was still nonetheless a decision that was not made
in public, and for that we can only now offer our apologies for this
mistake and learn a hard lesson from it.


It's simply not true that this is the only thing that can be done. You 
can hold off on making a decision, and follow an open process instead.



We do want to let you know that we deeply appreciate the requirements
you have given us and would like to ask you to continue engaging with
us while we are moving through our next steps with GitLab.


What would be the goal if the community were to continue to engage with 
CPE management when it has demonstrated that it does not meaningfully 
engage with the community?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Replace buildroot overrides with user side tags?

Also, it doesn't take NEAR as long for the package to be available in a
side tag then a buildroot override...

Been waiting almost an hour for one in f32...

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

[EPEL-devel] Re: Extras not enabled on koji?

On Sat, Apr 4, 2020 at 2:27 PM Stephen John Smoogen 
wrote:

>
> On Sat, 4 Apr 2020 at 14:54, Richard Shaw  wrote:
>
>> I'm trying to build a package that requires swig 3.0.12+. The version in
>> EPEL is way too old but swig3 is provided in the extras repo.
>>
>> I was able to build locally via mock and COPR fine, but when I tried
>> official builds it doesn't look like the "extras" repo is enabled.
>>
>> Is that on purpose?
>>
>>
> Which extras directory and which release of EL are you talking about? The
> one in CentOS is not the same as the one in RHEL and they have different
> things. EPEL builds against RHEL so that might affect things.
>

I use the Fedora CentOS 7 test instance as a test environment when trying
to track down available packages:

$ sudo yum list swig*
Loaded plugins: fastestmirror
Repository epel is listed more than once in the configuration
Repository epel-testing is listed more than once in the configuration
Loading mirror speeds from cached hostfile
 * base: d36uatko69830t.cloudfront.net
 * epel: mirrors.kernel.org
 * extras: d36uatko69830t.cloudfront.net
 * updates: d36uatko69830t.cloudfront.net
Available Packages
swig.x86_64 2.0.10-5.el7
  base
swig-doc.noarch 2.0.10-5.el7
  base
swig3.x86_643.0.12-17.el7
 extras
swig3-doc.noarch3.0.12-17.el7
 extras
swig3-gdb.x86_643.0.12-17.el7
 extras

Thanks,
Richard
___
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: Extras not enabled on koji?

2020-04-04 Thread Stephen John Smoogen

On Sat, 4 Apr 2020 at 14:54, Richard Shaw  wrote:

> I'm trying to build a package that requires swig 3.0.12+. The version in
> EPEL is way too old but swig3 is provided in the extras repo.
>
> I was able to build locally via mock and COPR fine, but when I tried
> official builds it doesn't look like the "extras" repo is enabled.
>
> Is that on purpose?
>
>
Which extras directory and which release of EL are you talking about? The
one in CentOS is not the same as the one in RHEL and they have different
things. EPEL builds against RHEL so that might affect things.



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


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

Fedora rawhide compose report: 20200404.n.0 changes

2020-04-04 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20200403.n.0
NEW: Fedora-Rawhide-20200404.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  4
Dropped packages:4
Upgraded packages:   182
Downgraded packages: 7

Size of added packages:  554.46 MiB
Size of dropped packages:4.96 MiB
Size of upgraded packages:   1.63 GiB
Size of downgraded packages: 34.02 MiB

Size change of upgraded packages:   354.94 MiB
Size change of downgraded packages: -2.73 KiB

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200403.n.0.ppc64le.qcow2
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200403.n.0.ppc64le.vmdk
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200403.n.0.ppc64le.raw.xz

= ADDED PACKAGES =
Package: eclipse-1:4.15-5.module_f33+8558+5e2e0c79
Summary: An open, extensible IDE
RPMs:eclipse-contributor-tools eclipse-equinox-osgi eclipse-jdt 
eclipse-p2-discovery eclipse-pde eclipse-platform eclipse-swt
Size:534.90 MiB

Package: eclipse-ecf-3.14.7-1.module_f33+8420+75d411ed
Summary: Eclipse Communication Framework (ECF) Eclipse plug-in
RPMs:eclipse-ecf-core eclipse-ecf-runtime eclipse-ecf-sdk
Size:4.51 MiB

Package: eclipse-emf-1:2.21.0-1.module_f33+8420+75d411ed
Summary: EMF and XSD Eclipse plug-ins
RPMs:eclipse-emf-core eclipse-emf-runtime eclipse-emf-sdk eclipse-emf-xsd
Size:14.90 MiB

Package: pam-cryptsetup-0.1-0.3.20190823.7b42892.fc33
Summary: PAM module for updating LUKS-encrypted volumes
RPMs:pam-cryptsetup
Size:151.41 KiB


= DROPPED PACKAGES =
Package: dspam-3.10.2-30.fc31
Summary: A library and Mail Delivery Agent for Bayesian SPAM filtering
RPMs:dspam dspam-client dspam-devel dspam-hash dspam-libs dspam-mysql 
dspam-pgsql dspam-sqlite3 dspam-web
Size:3.79 MiB

Package: fluxcapacitor-0-9.20180118gitf6c7f07.fc31
Summary: Run programs without blocking on syscalls
RPMs:fluxcapacitor
Size:85.28 KiB

Package: google-crosextra-carlito-fonts-1.103-0.12.20130920.fc32
Summary: Sans-serif font metric-compatible with Calibri font
RPMs:google-crosextra-carlito-fonts
Size:809.11 KiB

Package: rubygem-cocoon-1.2.6-12.fc32
Summary: Easier nested forms with standard forms, formtastic and simple-form
RPMs:rubygem-cocoon rubygem-cocoon-doc
Size:305.75 KiB


= UPGRADED PACKAGES =
Package:  aether-connector-okhttp-0.17.6-3.module_f33+8420+75d411ed
Old package:  aether-connector-okhttp-0.17.6-3.module_f33+8406+feb0be7b
Summary:  OkHttp Aether Connector
RPMs: aether-connector-okhttp aether-connector-okhttp-javadoc
Size: 115.91 KiB
Size change:  6 B

Package:  anaconda-33.7-1.fc33
Old package:  anaconda-33.6-1.fc33
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-live anaconda-tui anaconda-widgets 
anaconda-widgets-devel
Size: 19.44 MiB
Size change:  20.12 KiB
Changelog:
  * Fri Apr 03 2020 Martin Kolman  - 33.7-1
  - Don't clear errors by expanding pages in the custom spoke (vponcova)
  - Fix the permission for changing a mount point (#1818500) (vponcova)
  - Allow to use an existing unlocked LUKS in one special case (#1772902)
(vponcova)
  - Fix the encryption checkbox in the custom spoke (#1819360) (vponcova)
  - Don't manually trigger a device encryption change (vponcova)


Package:  antlr32-3.2-23.module_f33+8420+75d411ed
Old package:  antlr32-3.2-23.module_f33+8406+feb0be7b
Summary:  ANother Tool for Language Recognition
RPMs: antlr32-java antlr32-javadoc antlr32-maven-plugin antlr32-tool
Size: 1.55 MiB
Size change:  -2.42 KiB

Package:  apache-commons-collections-3.2.2-15.module_f33+8420+75d411ed
Old package:  apache-commons-collections-3.2.2-15.module_f33+8406+feb0be7b
Summary:  Provides new interfaces, implementations and utilities for Java 
Collections
RPMs: apache-commons-collections apache-commons-collections-javadoc 
apache-commons-collections-testframework
Size: 1.12 MiB
Size change:  -527 B

Package:  apache-commons-compress-1.19-1.module_f33+8420+75d411ed
Old package:  apache-commons-compress-1.19-1.module_f33+8406+feb0be7b
Summary:  Java API for working with compressed files and archivers
RPMs: apache-commons-compress apache-commons-compress-javadoc
Size: 1.05 MiB
Size change:  58 B

Package:  apache-commons-discovery-2:0.5-23.module_f33+8420+75d411ed
Old package:  apache-commons-discovery-2:0.5-23.module_f33+8406+feb0be7b
Summary:  Apache Commons Discovery
RPMs: apache-commons-discovery apache-commons-discovery-javadoc
Size: 174.53 KiB
Size change:  -78 B

Package:  apache-commons-jxpath-1.3-34.module_f33+8420+75d411ed
Old package:  apache-commons-jxpath-1.3-34.module_f33+8406+feb0be7b
Summary

CPE Weekly: 2020-04-04

2020-04-04 Thread Aoife Moloney

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

# CPE Weekly: 2020-03-06

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


## GitForge Updates
Idea for note:
*There has been a lot of discussion this week on the devel and infra
lists about the decision to move to GitLab in the near future.
Firstly, let us apologize again to the communities for our drop in
communication between the requirement collecting phase and the
decision making phase. As we have said before, it was in no way, shape
or form an intentional lapse of communications. However we do
recognize that it was still nonetheless a decision that was not made
in public, and for that we can only now offer our apologies for this
mistake and learn a hard lesson from it.
We do want to let you know that we deeply appreciate the requirements
you have given us and would like to ask you to continue engaging with
us while we are moving through our next steps with GitLab.
While the discussions on the lists are deeply emotional, they are
still incredibly valuable to us to truly comprehend the importance of
our next steps in ensuring we make the right choices in the coming
months.
Now more than ever, your guidance is needed to make sure we achieve
the best possible result for you and our team from this decision.
CPE management and I, our team's product owner, are also actively
engaging with the Fedora Council and soon the CentOS Board to make
sure that ALL of the developments and progress between us and GitLab
are publicly available.
We have a long way to go in this process and your feedback on our
progress will be vital to make sure we remain on course.
We hope in time you can understand our decision was made in good
intent for the betterment of both our team and the communities we
serve, and we hope to still be able to rely on you all as peers and
friends for feedback and guidance during this journey.*



## Fedora Updates
* Final Freeze starts 7th April 2020 @ 1400 UTC
* Pagure 5.9.1 release pushed to both staging and pagure.io
* the-new-hotness configuration was updated
https://pagure.io/fedora-infrastructure/issue/8783
* Michal Konečný has been working on mapping the fedora infrastructure
applications, his project, (which sounds really cool and useful!) can
be found here https://github.com/Zlopez/fedora-infra-map


### Data Centre Move
* Please note Communishift will be down from 13th April - 8th May to
facilitate the first shipment wave of our datacenter
* We are also still on track to switch to a reduced Fedora offering
from 25th May until est. 1st July\*.
* For a list of services we are planning to have available during this
window, please see mail thread in archive
https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/PN6RL7XT3V7DVC7MK46H3QDEJPL5FRI6/
* We will not have staging available so we will not have capacity to
review or deploy new or upgraded features and applications during this
time.
* As always, please view our public schedule here for more a more
detailed overview
https://hackmd.io/@fedorainfra2020/rJpsA4FLL#First-draft-of-schedule-for-PHX2--gt-IAD2-move
* We found a password, we do not know whose it is, but we have turned
it into the lost and found.


### AAA Replacement
* First development phase complete & the team worked through 57 tickets in total
* The codebase was sent to our team first for demo and we will be
using feedback to develop the portal further
* During phase two we would like to change some codebases in existing
apps, and write documentation on how to upgrade applications to
redirect to the new API
* We would like to roll this request for feedback out to some
community maintainers during this phase too for another iteration on
the service and documentation
* Our work is publicly tracked here
https://github.com/orgs/fedora-infra/projects/6 so please stop by and
check out the progress we are making, and what we are looking at
working on next



### CI/CD

* Monitor-gating is still running in production and giving us some
data about the health of the packager workflow:
* For example, these are the statistics between Monday and Wednesday:
39 messages retrieved
prod.monitor-gating.multi-build.end.failed  --  7
prod.monitor-gating.multi-build.end.succeeded  --  2
prod.monitor-gating.multi-build.start  --  10
prod.monitor-gating.single-build.end.failed  --  3
prod.monitor-gating.single-build.end.succeeded  --  7
prod.monitor-gating.single-build.start  --  10
* rpmautospec 0.0.1 through 0.0.10 have been released and deployed in staging
* We got two builds to go through fine, from the same commit,
getting two different NEVR and an auto-generated changelog
* However, for this to happen, we had to tweak a couple of things
on the builder which is not really ideal/acceptable, so we moved a

[EPEL-devel] Extras not enabled on koji?

I'm trying to build a package that requires swig 3.0.12+. The version in
EPEL is way too old but swig3 is provided in the extras repo.

I was able to build locally via mock and COPR fine, but when I tried
official builds it doesn't look like the "extras" repo is enabled.

Is that on purpose?

Thanks,
Richard
___
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 1820924] New: perl-Test-Most-0.37 is available

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

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



Latest upstream release: 0.37
Current version/release in rawhide: 0.36-1.fc33
URL: http://search.cpan.org/dist/Test-Most/

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


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


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


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


-- 
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: Updating MUMPS/Sundials/PETSc

2020-04-04 Thread David S


On 4/4/20 4:38 PM, Antonio Trande wrote:

Hi all.

`MUMPS-5.3.0` [1] `PETSc-3.13.0` [2] and `Sundials-5.2.0` [3] are coming
on Rawhide; these updates will need rebuilds of dependent packages:


[:snip:]


Thanks a lot for updating PETSc, I know PETSc is quite challenging to 
package.


I tried to build BOUT++ against PETSc, using pkg-config.
the pkg-config files are installed to petsc/ subdirectory, but it seems 
the pc files are not adjusted for this.


Further, I have been using petsc --with superludist without issues, can 
you tell why this was disabled, so I can test whether this was fixed in 
the mean time?


[1]
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1327044/
[2]
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1327319/
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=43020532


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

Fedora 32 compose report: 20200404.n.0 changes

2020-04-04 Thread Fedora Branched Report

OLD: Fedora-32-20200403.n.0
NEW: Fedora-32-20200404.n.0

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

Size of added packages:  32.68 MiB
Size of dropped packages:17.12 KiB
Size of upgraded packages:   2.43 GiB
Size of downgraded packages: 139.55 KiB

Size change of upgraded packages:   40.50 MiB
Size change of downgraded packages: -1.29 KiB

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: algobox-1.0.3-1.fc32
Summary: Algorithmic software
RPMs:algobox
Size:2.77 MiB

Package: dnstwist-20190706-3.fc32
Summary: Domain name permutation engine
RPMs:dnstwist
Size:91.48 KiB

Package: goloris-0-0.1.20200326gita59fafb.fc32
Summary: Slowloris for NGINX DoS
RPMs:golang-github-valyala-goloris-devel goloris
Size:7.16 MiB

Package: libqmatrixclient-0.5.2-1.fc32
Summary: Qt5 library to write cross-platform clients for Matrix
RPMs:libqmatrixclient libqmatrixclient-devel
Size:3.41 MiB

Package: non-daw-1.2.0-19.20200307gitbbe8386.fc32
Summary: A digital audio workstation for JACK
RPMs:non-daw non-mixer non-mixer-doc non-sequencer non-sequencer-doc 
non-session-manager non-session-manager-doc
Size:16.96 MiB

Package: python-asysocks-0.0.2-1.fc32
Summary: Socks5/Socks4 client and server library
RPMs:python3-asysocks
Size:33.62 KiB

Package: python-bibtexparser-1.1.0-2.fc32
Summary: A BibTeX parsing library
RPMs:python-bibtexparser-doc python3-bibtexparser
Size:316.87 KiB

Package: python-friendlyloris-1.0.1-1.fc32
Summary: A Slow Loris package for Python
RPMs:python3-friendlyloris
Size:15.08 KiB

Package: python-makeelf-0.3.2-1.fc32
Summary: ELF reader-writer library
RPMs:python3-makeelf
Size:56.95 KiB

Package: python-readability-lxml-0.7.1-2.20200326gitede4d01.fc32
Summary: Fast html to text parser (article readability tool)
RPMs:python3-readability-lxml
Size:40.12 KiB

Package: python-requests-pkcs12-1.7-1.fc32
Summary: Add PKCS12 support to the requests library
RPMs:python3-requests-pkcs12
Size:14.19 KiB

Package: python-whois-0.9.6-2.fc32
Summary: Python module for retrieving WHOIS information of domains
RPMs:python3-whois
Size:22.68 KiB

Package: quaternion-0.0.9.4c-1.fc32
Summary: A Qt5-based IM client for Matrix
RPMs:quaternion
Size:1.76 MiB

Package: slowloris-0.2.0-1.fc32
Summary: Low bandwidth DoS tool
RPMs:python3-slowloris slowloris
Size:19.46 KiB

Package: vim-rhubarb-0-2.20191014git513059.fc32
Summary: GitHub support for vim-fugitive plugin
RPMs:vim-rhubarb
Size:11.06 KiB


= DROPPED PACKAGES =
Package: gnome-shell-extension-no-topleft-hot-corner-19.0-3.fc32
Summary: Disable the "hot corner" in the top-left of GNOME Shell
RPMs:gnome-shell-extension-no-topleft-hot-corner
Size:17.12 KiB


= UPGRADED PACKAGES =
Package:  HepMC3-3.2.1-1.fc32
Old package:  HepMC3-3.2.0-2.fc32
Summary:  C++ Event Record for Monte Carlo Generators
RPMs: HepMC3 HepMC3-devel HepMC3-doc HepMC3-interfaces-devel 
HepMC3-rootIO HepMC3-rootIO-devel HepMC3-search HepMC3-search-devel 
python3-HepMC3 python3-HepMC3-rootIO python3-HepMC3-search
Size: 44.27 MiB
Size change:  302.66 KiB
Changelog:
  * Tue Jan 28 2020 Mattias Ellert  - 3.2.0-3
  - Add Python 3.9 as a valid Python version

  * Sun Mar 22 2020 Mattias Ellert  - 3.2.1-1
  - Update to version 3.2.1
  - Drop patches accepted upstream or previously backported
  - Fix glitches in the generation of the HepMC3-config script
  - Add additional Python 3 version package for EPEL 7
(cmake configuration now supports multiple Python 3 versions)
  - Use new cmake configuration options -DHEPMC3_ROOTIO_INSTALL_LIBDIR and
-DHEPMC3_BUILD_STATIC_LIBS and simplify spec file accordingly
  - .egg-info filenames are now correct - auto generated provides work


Package:  NetworkManager-l2tp-1.8.2-1.fc32
Old package:  NetworkManager-l2tp-1.8.0-5.fc32
Summary:  NetworkManager VPN plugin for L2TP and L2TP/IPsec
RPMs: NetworkManager-l2tp NetworkManager-l2tp-gnome
Size: 1.08 MiB
Size change:  3.37 KiB
Changelog:
  * Thu Mar 26 2020 Douglas Kosovic  - 1.8.2-1
  - Updated to 1.8.2 release
  - Remove redundant patches
  - Recommends (libreswan or strongswan) instead of just libreswan


Package:  R-RInside-0.2.16-1.fc32
Old package:  R-RInside-0.2.15-6.fc32
Summary:  C++ Classes to Embed R in C++ (and C) Applications
RPMs: R-RInside R-RInside-devel R-RInside-examples
Size: 816.93 KiB
Size change:  69.36 KiB
Changelog:
  * Fri Mar 20 2020 Mattias Ellert  - 0.2.16-1
  - New release 0.2.16


Package:  R-Rcpp-1.0.4-2.fc32
Old package:  R-Rcpp-1.0.3-3.fc32
Summary:  Seamless R and C++ Integration
RPMs: R-Rcpp R-Rcpp-devel R-Rcpp-examples
Size: 10.73 MiB
Size change:  -24.36 KiB
Changelog:
  * Fri M

Heads-up: updating Clojure to 1.9 in rawhide

2020-04-04 Thread Markku Korkeala

Hi,

I'm the process updating package Clojure to 1.9 in rawhide, this will

require few alpha/beta releases to get new required dependencies built
as well.

Best regards,

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

2020-04-04 Thread Todd Zullinger

Hi Ivan.

Ivan Chavero wrote:
> Are there any plans to upgrade the spec file of rubygem-asciidoctor for
> Fedora 31 to the 2.0.10 version?

Unfortunately, I don't think it would be an appropriate
update for Fedora 31.  And update from 1.5.6 to 2.0.10 would
cause some package builds to break and that would be
needless pain for maintainers on F31 -- particularly those
who might need to push an important bugfix or security
update.

It was unfortunate that we missed the window to get the
2.0.10 update into Fedora 31 before it was released.
Hopefully things will stay closer to upstream going forward.

My main interest in asciidoctor stems from using it for
building Git's documentation.  Upstream Git has done some
great work to make asciidoctor well-supported as an
alternative to asciidoc in the past few releases.  I
switched the Fedora git packages to asciidoctor recently
(even on Fedora 31 with its older asciidoctor release).

-- 
Todd

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

Updating MUMPS/Sundials/PETSc

2020-04-04 Thread Antonio Trande

Hi all.

`MUMPS-5.3.0` [1] `PETSc-3.13.0` [2] and `Sundials-5.2.0` [3] are coming
on Rawhide; these updates will need rebuilds of dependent packages:

$ repoquery --release rawhide --whatrequires MUMPS-devel --disablerepo=*
--enablerepo=fedora-*-source --enablerepo=updates*-source
Last metadata expiration check: 0:01:42 ago on sab 4 apr 2020, 17:17:00.
coin-or-Cbc-0:2.10.5-1.fc33.src
coin-or-Clp-0:1.17.5-1.fc33.src
coin-or-Ipopt-0:3.13.0-1.fc33.src
freefem++-0:4.4.2-2.fc32.src
mld2p4-0:2.2.1-5.fc32.src

$ repoquery --release rawhide --whatrequires sundials-devel
--disablerepo=* --enablerepo=fedora-*-source --enablerepo=updates*-source
Last metadata expiration check: 0:01:57 ago on sab 4 apr 2020, 17:17:00.
dolfin-0:2019.1.0.post0-2.fc32.src
octave-6:5.2.0-1.fc32.src

$ repoquery --release rawhide --whatrequires petsc-devel --disablerepo=*
--enablerepo=fedora-*-source --enablerepo=updates*-source
Last metadata expiration check: 0:02:12 ago on sab 4 apr 2020, 17:17:00.
dolfin-0:2019.1.0.post0-2.fc32.src
freefem++-0:4.4.2-2.fc32.src
getdp-0:3.3.0-2.fc32.src

[1]
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1327044/
[2]
https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/build/1327319/
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=43020532

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
GPG key server: https://keys.openpgp.org/



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

Re: CPE Git Forge Decision

2020-04-04 Thread clime

On Sat, 4 Apr 2020 at 14:04, Neal Gompa  wrote:
>
> On Fri, Apr 3, 2020 at 9:42 PM Randy Barlow
>  wrote:
> >
> > On 4/3/20 4:41 PM, Leigh Griffin wrote:
> > > We didn't quash communication for reasons already mentioned. We didn't
> > > facilitate it is a more accurate assessment, for which we have
> > > acknowledged and apologized.
> >
> > You certainly didn't engage with the community. Fedora has a change
> > process, and every other significant change goes through it. Sure, not
> > everyone is happy with the results of every decision, but there is at
> > least open discussion. That open discussion often influences the
> > decision. You didn't do that here, and the only communication of the
> > decision was buried in an e-mail that many people don't read. That
> > communication was also a decision, not an invitation for discussion.
> > There is no process now for discussion to influence the decision, a
> > cornerstone of open development.
> >
> > This is not open.
>
> I'd like to point out *every other major infrastructure change* has
> gone through the change process, debated publicly, and approved by
> FESCo before implementing:
>
> * Merged Core and Extras in our CVS:
> https://fedoraproject.org/wiki/Releases/FeatureMergeSCM
> * Deployment of Koji:
> https://fedoraproject.org/wiki/Releases/FeatureNewBuildSystem
> * Deployment of Bodhi:
> https://fedoraproject.org/wiki/Releases/FeatureUpdateSystem
> * Deployment of Dist-Git: https://fedoraproject.org/wiki/Dist_Git_Proposal
> * Koji signed repos: https://fedoraproject.org/wiki/Changes/KojiSignedRepos
> * Deployment of Pagure:
> https://fedoraproject.org/wiki/Changes/ArbitraryBranching
> * Deployment of MBS: https://fedoraproject.org/wiki/Changes/ModuleBuildService
> * Added Modular Compose: https://fedoraproject.org/wiki/Changes/ModularCompose
> * Added Zchunk repodata: 
> https://fedoraproject.org/wiki/Changes/Zchunk_Metadata
> * Gated Rawhide: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
> * Dropped i686 content:
> https://fedoraproject.org/wiki/Changes/Noi686Repositories
> * Fedora active user metrics:
> https://fedoraproject.org/wiki/Changes/DNF_Better_Counting
> * Using Taiga for the Change proposals:
> https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
> * Enabling modules in the regular buildroot:
> https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
>
> If we were to consider this as the requisite community discussion and
> the decision as a "proposal", then the resounding negative feedback
> would be sufficient to *not* do this without going back to the drawing
> board and improving the proposal.
>
> But of course, that's not what is happening. And that's a problem in
> itself. We accepted the deviation in procedure for Fedora
> infrastructure changes for *this* change because there was a described
> process that was considered functionally equivalent. But then *that*
> process was not followed. You've effectively shattered the trust with
> the community that you attempted to create with this.

Yes, this whole "decision" is in dictatorship relation to the community.

Not following the standard procedures caused that I and probably many
people in the community didn't pay much attention to it.

I thought you are simply going to collect requirements and then we
will talk. Collecting the requirements was actually very useful.
Providing the analysis for the requirements would be useful. Providing
a recommendation would be ok. Providing a "decision" like that crosses
the line.

It sends quite a bad message that no matter what you start doing for
the community and how useful it becomes, RH management can come at any
time and make your work vanish, which is what is happening here with
pagure on dist-git effort and probably also zuul efforts might get
replaced by Gitlab CI.

Additionally, I think that disruption you will cause will take so much
time that it would several-times cover the time needed for
implementation of all of the features people want to see in pagure.

I also don't see people on IRC complaining that pagure.io or src.fp.o
doesn't work so maintenance-wise it doesn't seem to be causing
problems (there might be some but I didn't notice).

In other words, the change you are suggesting won't be imho good for
Fedora. What would be good is to continue doing incremental
well-thought changes and not give up on our products. That might
result in them coming on top at one point.

I consider this whole situation my mistake. For quite some time I
wanted to bring improvements to the packaging area to show that we can
have top-notch stuff ourselves but it got seriously delayed by me not
being always on top of my game. I still want to finish this
(https://github.com/rpm-software-management/mock/pull/526) but I
regret I didn't go for it earlier.

But still, please, listen to what the community is telling you. While
you may have means to force your decision as RH management
representative, doing so can be

[Test-Announce] Fedora 32 Branched 20200404.n.0 nightly compose nominated for testing

2020-04-04 Thread rawhide

Announcing the creation of a new nightly release validation test event
for Fedora 32 Branched 20200404.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20200401.n.1: anaconda-32.24.3-1.fc32.src, 20200404.n.0: 
anaconda-32.24.4-1.fc32.src

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

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

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200404.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200404.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200404.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200404.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200404.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200404.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Branched_20200404.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: %bcond_with/%bcond_without

2020-04-04 Thread Zbigniew Jędrzejewski-Szmek

On Sat, Apr 04, 2020 at 11:31:04AM +0200, Aleksandra Fedorova wrote:
> Hi,
> 
> On Fri, Apr 3, 2020 at 10:38 PM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > On Fri, Apr 03, 2020 at 02:23:12PM -0400, Stephen Gallagher wrote:
> > > Fabio Valenti made this comment in the FESCo ticket[1].
> > >
> > > "Side note: I think more people would be amenable to including
> > > "conditionals" into their packages if they weren't only shown off as
> > > `%if eln this else that`. I think there's more value in doing "feature
> > > flags" rather than conditionalize everything based on the `dist` tag,
> > > for example something like this might even be useful in fedora
> > > branches (e.g. for bootstrapping):
> > >
> > > ```spec
> > > # at the top of the .spec file, where it's easily visible
> > > %if 0%{?eln}
> > > %bcond_with docs
> > > %else
> > > %bconf_without docs
> > > %endif
> > >
> > > # ...
> > >
> > > %if %{with docs}
> > > # do something
> > > %endif
> > > ```
> > >
> > > This makes conditionals (when they are necessary) much easier to
> > > maintain (and understand), in my experience."
> >
> > This is a side topic, and I didn't want to clutter the FESCo ticket
> > with that. But here we have threads, so I hope that you'll forgive me ;)
> >
> > If find the %bcond_with/%bcond_without pattern abhorrent.
> >
> > 1. The logic is reversed: when I see "with" I think something is enabled,
> >when I see "without" I think something is disabled. But it's actually
> >the other way around here, which I find very confusing and often get
> >the condition reversed on the first try.
> >
> > 2. The value ('0%{?eln}') in this example is expressed before the name
> >('docs'), which is like saying 'value =: name'.
> >
> > 3. It takes five (!) lines to express the something that should be one
> >line.
> >
> > So... could we please get a way to express this in rpm with a sane syntax:
> >
> > %define_cond docs 0%{?fedora} > 0
> 
> I am all for clarity and cleaner syntax.
> But I don't think this particular example is a good illustration for
> it. If we have more then one switch, or more than one set of switches
> it won't work.
> 
> Something like:
> 
> %if 0%{?fedora} > 0
> %define_cond docs 1
> %define_cond tests 1
> %endif
> 
> %if 0%{?rhel} > 0
> %define_cond docs 0
> %define_cond tests 1
> %endif
> 
> is more readable than
> 
> %define_cond docs 0%{?fedora} > 0
> %define_cond tests (0%{?fedora} > 0 OR 0%{?rhel} > 0)
> 
> even though there are more lines in it.

This is not what we were discussing. This should be compared with
%bcond_with/%bcond_without, which would looks like this:

%if 0%{?fedora} > 0
%bcond_without docs
%bcond_without tests
%endif

%if 0%{?rhel} > 0
%bcond_with docs
%bcond_without tests
%endif

Which IMO clearly loses the contest.

Returning to the one-definition vs. multiple-definitions issue:
I think I'd prefer the shorter version, though I admit it's pretty
close in this case.

The biggest usage problem is that rpm does not verify that everything
is assigned, so (with a longer list) it's fairly easy to forget to
define one of the items in one of the cases, silently leaving a
feature disabled.

Also, things quickly get complicated when issues depend on one another:
%define_cond docs 0%{?fedora} > 0 || 0%{rhel} >= 8
%define_cond tests 1
%define_cond doc-tests %{with_docs} && %{with_tests} && 0%{?rhel} >= 9

Ideally, we would be able to do both, and e.g. in this case use
the "verbose" style for the first two switches, and the one-line style
for the third condition.

Zbyszek

P.S. '%bcond  ' suggested in [1] is clearly a better
name than '%define_cond'.

[1] https://github.com/rpm-software-management/rpm/issues/941
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora-IoT-32-20200404.0 compose check report

2020-04-04 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 1/8 (x86_64)

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

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

Passed openQA tests: 7/8 (x86_64)

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

Re: New set of questions for FESCo candidates?

On Mon, Nov 4, 2019 at 8:59 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> Dear all,
>
> the semiannual exercise is upon us. FESCo candidates must submit an
> "interview" in which they answer a set of questions (but can also add
> whatever they want).
> The question whether we should have a new set of questions needs to be
> answered.


With the recent gitlab discussions pointing out that for newer volunteers
that a lot of the infrastructure it very opaque to them, it may be good to
not rely on abbreviations (FESCo) until it's defined and perhaps provide a
link to their structure and purpose.

Fedora Engineering Steering Committee

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

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

Re: Replace buildroot overrides with user side tags?

On Sat, Apr 4, 2020 at 8:46 AM Miro Hrončok  wrote:

> > Just to simply things I would be in favor of using side tags across the
> board
> > and dropping buildroot overrides but there's probably some situations
> I'm not
> > thinking of.
>
> For an update that can potentially break other packages building, I submit
> a
> buildroot override before pushing it to stable to see how the Koschei
> builds are
> affected. That could be solved on Koschei level by including
> updates-testing by
> default somehow.
>

Ok, yeah, it's not practical (or necessary) to rebuild all
dependent packages in cases like that. I've only done the typical major
library update and rebuild all dependencies. The biggest one of which has
10 packages needing rebuilding.

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

[EPEL-devel] Fwd: Modularity Survey

If you have questions or comments about the survey to discuss on the
mailing list, use this thread:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/NAACOHBWTKAZN3IOQKWDNTEHS2BQ6OVJ/

-- Forwarded message -
From: Daniel Mach 
Date: Fri, Apr 3, 2020 at 9:54 AM
Subject: Modularity Survey
To: Development discussions related to Fedora 

Hello everyone,

On behalf of Red Hat's Modularity team, I'd like to ask you to fill out
a survey on Modularity:
https://docs.google.com/forms/d/e/1FAIpQLScOA97rGONieSOYmlZLsHdkq-EhdePZ4IN3RwOjJKd1F1a9sw/viewform?usp=sf_link

Our goal is to use your feedback to improve Modularity, its
documentation and hopefully fix any issues you may have.

Modularity Survey
-
The purpose of this survey is to get feedback on Modularity.

It is divided into 4 sections:
* Information about yourself (optional)
* Modularity & you
* Problems with Modularity you may have experienced
* Glossary review - what do you think the terms mean

Privacy / GDPR:
* The raw data incl. any personal information you provide will be shared
only with Red Hat's Modularity team (approx. 10 people) to evaluate the
survey
* The raw data will not be provided to anyone else at Red Hat or any 3rd
parties
* Aggregated (anonymous) results of the survey will be published

Thank you for your cooperation.
___
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: New set of questions for FESCo candidates?


On 04. 11. 19 15:58, Zbigniew Jędrzejewski-Szmek wrote:

Dear all,

the semiannual exercise is upon us. FESCo candidates must submit an
"interview" in which they answer a set of questions (but can also add whatever 
they want).
The question whether we should have a new set of questions needs to be answered.

Currently we have the following:

Mandatory Question #1: Describe some of the important technical issues
you foresee affecting the Fedora community. What insight do you bring
to these issues?

Mandatory Question #2: What objectives or goals should FESCo focus on
to help keep Fedora on the cutting edge of open source development?

Mandatory Question #3: What are the areas of the distribution and our
processes that, in your opinion, need improvement the most? Do you
have any ideas how FESCo would be able to help in those "trouble
spots"?

Please answer with any proposals. If there is sufficient support for
change, I'll gather a list and submit this for some kind of poll
(details to be figured out...).


It is this time of year again.

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

Re: Replace buildroot overrides with user side tags?


On 04. 04. 20 14:56, Richard Shaw wrote:
Perhaps this has been discussed already but I found the new user side tags a 
much easier process than using buildroot overrides.


Is the only *effective* difference that with a buildroot override that 
*everyone* can use it (on purpose or not) and with side tags only the creator 
(or users shared to) can use the package?


Yes please! Especially for highly depended on packages (e.g. gcc/annobin), this 
should really be the default.


Just to simply things I would be in favor of using side tags across the board 
and dropping buildroot overrides but there's probably some situations I'm not 
thinking of.


For an update that can potentially break other packages building, I submit a 
buildroot override before pushing it to stable to see how the Koschei builds are 
affected. That could be solved on Koschei level by including updates-testing by 
default somehow.


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

Re: Replace buildroot overrides with user side tags?

On Sat, Apr 4, 2020 at 8:23 AM Neal Gompa  wrote:

> On Sat, Apr 4, 2020 at 8:57 AM Richard Shaw  wrote:
> >
> > Perhaps this has been discussed already but I found the new user side
> tags a much easier process than using buildroot overrides.
> >
> > Is the only *effective* difference that with a buildroot override that
> *everyone* can use it (on purpose or not) and with side tags only the
> creator (or users shared to) can use the package?
> >
> > Just to simply things I would be in favor of using side tags across the
> board and dropping buildroot overrides but there's probably some situations
> I'm not thinking of.
> >
>
> That is pretty much the only difference. That said, anyone can build
> in a particular side tag once it's created, so I think this matters a
> lot less than people would think.
>

Ok, so they just need to know the name of the side tag, whereas buildroot
overrides you get it whether you want it or not.

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

Re: Replace buildroot overrides with user side tags?

On Sat, Apr 4, 2020 at 8:57 AM Richard Shaw  wrote:
>
> Perhaps this has been discussed already but I found the new user side tags a 
> much easier process than using buildroot overrides.
>
> Is the only *effective* difference that with a buildroot override that 
> *everyone* can use it (on purpose or not) and with side tags only the creator 
> (or users shared to) can use the package?
>
> Just to simply things I would be in favor of using side tags across the board 
> and dropping buildroot overrides but there's probably some situations I'm not 
> thinking of.
>

That is pretty much the only difference. That said, anyone can build
in a particular side tag once it's created, so I think this matters a
lot less than people would think.

I think once the side tag update workflow becomes more performant and
reliable, we probably could eliminate the usage of overrides.




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

Replace buildroot overrides with user side tags?

Perhaps this has been discussed already but I found the new user side tags
a much easier process than using buildroot overrides.

Is the only *effective* difference that with a buildroot override that
*everyone* can use it (on purpose or not) and with side tags only the
creator (or users shared to) can use the package?

Just to simply things I would be in favor of using side tags across the
board and dropping buildroot overrides but there's probably some situations
I'm not thinking of.

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

Re: %bcond_with/%bcond_without

On Sat, Apr 4, 2020 at 4:32 AM Aleksandra Fedorova 
wrote:

> Something like:
>
> %if 0%{?fedora} > 0
> %define_cond docs 1
> %define_cond tests 1
> %endif
>
> %if 0%{?rhel} > 0
> %define_cond docs 0
> %define_cond tests 1
> %endif
>

Isn't the >0 superfluous?  Just the "%if 0%{?fedora}" will evaluate as TRUE.

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

Re: CPE Git Forge Decision

On Fri, Apr 3, 2020 at 9:42 PM Randy Barlow
 wrote:
>
> On 4/3/20 4:41 PM, Leigh Griffin wrote:
> > We didn't quash communication for reasons already mentioned. We didn't
> > facilitate it is a more accurate assessment, for which we have
> > acknowledged and apologized.
>
> You certainly didn't engage with the community. Fedora has a change
> process, and every other significant change goes through it. Sure, not
> everyone is happy with the results of every decision, but there is at
> least open discussion. That open discussion often influences the
> decision. You didn't do that here, and the only communication of the
> decision was buried in an e-mail that many people don't read. That
> communication was also a decision, not an invitation for discussion.
> There is no process now for discussion to influence the decision, a
> cornerstone of open development.
>
> This is not open.

I'd like to point out *every other major infrastructure change* has
gone through the change process, debated publicly, and approved by
FESCo before implementing:

* Merged Core and Extras in our CVS:
https://fedoraproject.org/wiki/Releases/FeatureMergeSCM
* Deployment of Koji:
https://fedoraproject.org/wiki/Releases/FeatureNewBuildSystem
* Deployment of Bodhi:
https://fedoraproject.org/wiki/Releases/FeatureUpdateSystem
* Deployment of Dist-Git: https://fedoraproject.org/wiki/Dist_Git_Proposal
* Koji signed repos: https://fedoraproject.org/wiki/Changes/KojiSignedRepos
* Deployment of Pagure:
https://fedoraproject.org/wiki/Changes/ArbitraryBranching
* Deployment of MBS: https://fedoraproject.org/wiki/Changes/ModuleBuildService
* Added Modular Compose: https://fedoraproject.org/wiki/Changes/ModularCompose
* Added Zchunk repodata: https://fedoraproject.org/wiki/Changes/Zchunk_Metadata
* Gated Rawhide: https://fedoraproject.org/wiki/Changes/GatingRawhidePackages
* Dropped i686 content:
https://fedoraproject.org/wiki/Changes/Noi686Repositories
* Fedora active user metrics:
https://fedoraproject.org/wiki/Changes/DNF_Better_Counting
* Using Taiga for the Change proposals:
https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
* Enabling modules in the regular buildroot:
https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot

If we were to consider this as the requisite community discussion and
the decision as a "proposal", then the resounding negative feedback
would be sufficient to *not* do this without going back to the drawing
board and improving the proposal.

But of course, that's not what is happening. And that's a problem in
itself. We accepted the deviation in procedure for Fedora
infrastructure changes for *this* change because there was a described
process that was considered functionally equivalent. But then *that*
process was not followed. You've effectively shattered the trust with
the community that you attempted to create with this.

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

bodhi: Failed to talk to Greenwave.

2020-04-04 Thread Marius Schwarz


Hi,

ATM the Tab "Automated Test Results" shows just is message:

Failed to talk to Greenwave.

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

Re: Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3

2020-04-04 Thread Petr Viktorin


On 2020-04-03 14:43, Aleksandra Fedorova wrote:

On Fri, Apr 3, 2020 at 11:59 AM Petr Viktorin  wrote:


On 2020-04-02 20:07, Stephen Gallagher wrote:

On Thu, Apr 2, 2020 at 12:56 PM Miro Hrončok  wrote:

The change proposal received overly negative feedback by the packager community
as represented both by RHEL¹ and non-RHEL maintainers. Despite being reworked
several times, none of this feedback was reflected in the proposal, only new
reasons why this is going to be done the original way were added. It seems that
feedback is collected not to find the best technical solution, but rather to
find ways to justify a solution that's already decided.



This is needlessly antagonistic, Miro. We've collected the feedback in
good faith, examined it and then identified shortcomings with it. For
the sake of clarity in the Change Proposal, I've recorded that
reasoning there.


Key questions in the *Detailed Description* remain "out of scope of ELN" or not
answered clearly.


If something is not clear, please constructively offer that
information. I've been doing my best to rephrase and clarify anything
that has come up. Anything remaining that is "out of scope of ELN" is
literally just that. ELN's scope is largely "Make Fedora Rawhide more
useful to downstream so that downstream developers will work there
instead of internally".


# What if packages don't build on ELN?

The question isn't actually answered. Instead, the proposal answers
*how* packages will fail to build in ELN.


These are linked topics.

ELN is a "build profile" applied to Fedora Rawhide sources. If we take
a working Fedora Rawhide content and apply build profile to it, and it
breaks, then there two reasons why it may break:
1) the content is different because of the conditional, and this
conditional is broken. So we fix it.
2) the build profile is different, then we fix the buildroot and build
flags, and pungi config.

As we have a working baseline, it means that eventually if we reduce
the number of differences we reach the working state. Once we have
that working state we can start _adding_ differences again while
keeping it in a working state.


# If a package fails to build on ELN, what will happen?

What will the time limit be?
What exactly happens is a maintainer rejects the pull request?

# What if there is a new upstream feature RHEL wants in a package, how
will that go in?

Why is this not in scope? We're bringing RHEL development closer to
Fedora development. Non-Red Hatters don't know how a feature gets into
RHEL, and I don't blame them if they think this will affect their
workflow. Will it? How?


It is not a new thing which ELN changes. Red Hat developers have
always been working with Fedora on changes. If feature makes sense to
Fedora, it is not a matter of the ELN build, it is a matter of
bringing it to Fedora Rawhide.
ELN is not involved in this process.


OK, so would the following answer be correct?
That is not in the scope of ELN. As in the past, the feature can be 
either added to Fedora (and ELN) on its own merits, or it can be added 
directly to RHEL without affecting Fedora (and ELN) at all.



# What if I do not want to have %if's in my spec files?

What happens if ELN SIG cannot find a solution the maintainer is
comfortable with?


Again, we use raw Fedora Rawhide packages which work.


And if they don't work in ELN, it's up to the ELN SIG to make Rawhide 
packages work there. Right?



# What if I do not want to have %if's in my spec files, but I want to
see how changes show up in RHEL?

Sorry, but the answer reminds me of Modularity promises that the missing
pieces will be ready in the future.
What will the maintainer actually be expected to do in this case?


In Fedora - nothing. ELN is not the answer to all the wishes. And we
don't promise that we will ever cover this case in ELN. I don't see
any similarities with Modularity here.


The proposal should address the impact on all major packaging
styles, and while one side of the spectrum (packagers preferring single-spec
with conditionals) is covered, there are very few concrete details on the other
(packagers interested in simple spec files or completely uninterested in RHEL).
The affected packagers are concerned that the current proposal does not in fact
benefit Fedora (to an extent that would justify the disruptions), but rather
addresses mainly a downstream RHEL concern using Fedora's resources.


This is a great example of the Nirvana Fallacy. Essentially, you are
arguing that improvements for one group is not acceptable unless it
improves things for every other group too.


It doesn't have to *improve* things for the other group, but if not, it
should clearly acknowledge that it makes things worse (or the same), and
say how. Otherwise that group will justifiably feel excluded.

Say a new package is added to RHEL, which was previously only in Fedora.
The packager doesn't want RHEL conditionals in the spec. The change
doesn't make sense upstream or in Fedora (for

[Bug 1820848] perl-Test-Most-0.36 is available

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Test-Most-0.36-1.fc33
 Resolution|--- |RAWHIDE
   Assignee|jples...@redhat.com |p...@city-fan.org
   Doc Type|--- |If docs needed, set a value
Last Closed||2020-04-04 10:12:58



--- Comment #1 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=43018448


-- 
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: %bcond_with/%bcond_without

2020-04-04 Thread Aleksandra Fedorova

Hi,

On Fri, Apr 3, 2020 at 10:38 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Fri, Apr 03, 2020 at 02:23:12PM -0400, Stephen Gallagher wrote:
> > Fabio Valenti made this comment in the FESCo ticket[1].
> >
> > "Side note: I think more people would be amenable to including
> > "conditionals" into their packages if they weren't only shown off as
> > `%if eln this else that`. I think there's more value in doing "feature
> > flags" rather than conditionalize everything based on the `dist` tag,
> > for example something like this might even be useful in fedora
> > branches (e.g. for bootstrapping):
> >
> > ```spec
> > # at the top of the .spec file, where it's easily visible
> > %if 0%{?eln}
> > %bcond_with docs
> > %else
> > %bconf_without docs
> > %endif
> >
> > # ...
> >
> > %if %{with docs}
> > # do something
> > %endif
> > ```
> >
> > This makes conditionals (when they are necessary) much easier to
> > maintain (and understand), in my experience."
>
> This is a side topic, and I didn't want to clutter the FESCo ticket
> with that. But here we have threads, so I hope that you'll forgive me ;)
>
> If find the %bcond_with/%bcond_without pattern abhorrent.
>
> 1. The logic is reversed: when I see "with" I think something is enabled,
>when I see "without" I think something is disabled. But it's actually
>the other way around here, which I find very confusing and often get
>the condition reversed on the first try.
>
> 2. The value ('0%{?eln}') in this example is expressed before the name
>('docs'), which is like saying 'value =: name'.
>
> 3. It takes five (!) lines to express the something that should be one
>line.
>
> So... could we please get a way to express this in rpm with a sane syntax:
>
> %define_cond docs 0%{?fedora} > 0

I am all for clarity and cleaner syntax.
But I don't think this particular example is a good illustration for
it. If we have more then one switch, or more than one set of switches
it won't work.

Something like:

%if 0%{?fedora} > 0
%define_cond docs 1
%define_cond tests 1
%endif

%if 0%{?rhel} > 0
%define_cond docs 0
%define_cond tests 1
%endif

is more readable than

%define_cond docs 0%{?fedora} > 0
%define_cond tests (0%{?fedora} > 0 OR 0%{?rhel} > 0)

even though there are more lines in it.

>
> (Naming and details of syntax are just examples, but the important
> parts are: one line, name before value, positive logic).
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


-- 
Aleksandra Fedorova
bookwar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: koji wait-repo (newRepo) is really taking a long time

2020-04-04 Thread Richard W.M. Jones

On Sat, Apr 04, 2020 at 12:42:29AM +0200, Miro Hrončok wrote:
> On 03. 04. 20 13:03, Richard W.M. Jones wrote:
> >
> >I've been waiting on:
> >
> >$ koji wait-repo f33-build-side-20855 --build=ocaml-lacaml-9.3.2-17.fc33
> >
> >for hours now.  Seems like newRepo generation is again taking a very
> >long time?
> >
> >Also it'd be nice if this command didn't time out after 2 hours
> >(seems like a very odd and arbitrary choice - why not wait forever?)
> >and also coped with transient network failures.
> 
> For timeout, there is:
> 
>   --timeout=TIMEOUT  Amount of time to wait (in minutes) before giving up
>  (default: 120)
> 
> For network issues, I've been using:
> 
> while ! koji wait-repo ...; do sleep 15; done
> 
> ...quite successfully.

Thanks, hopefully with this change it'll be more robust:

http://git.annexia.org/?p=goals.git;a=commitdiff;h=cda1f0160b96e57a0037085f33aa2d440453a30b

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

Fedora-Cloud-31-20200404.0 compose check report

2020-04-04 Thread 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 1820848] New: perl-Test-Most-0.36 is available

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

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



Latest upstream release: 0.36
Current version/release in rawhide: 0.35-12.fc32
URL: http://search.cpan.org/dist/Test-Most/

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


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


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


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


-- 
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: @core install picking up desktop packages

2020-04-04 Thread Zbigniew Jędrzejewski-Szmek

On Fri, Apr 03, 2020 at 02:25:36PM +0200, Kalev Lember wrote:
> On Fri, Apr 3, 2020 at 2:18 PM Jan Pazdziora  wrote:
> 
> > The dependency chain from @core to gtk3 and fonts actually goes from
> > gnupg2, required by dnf, which recommends pinentry, which requires
> > libsecret-1.so.0()(64bit), which then recommends gnome-keyring, which
> > requires /usr/libexec/gcr-ssh-askpass, which comes from gcr, which
> > requires libgtk-3.so.0()(64bit) and libpango-1.0.so.0()(64bit).
> >
> 
> I added the libsecret -> gnome-keyring recommends due to
> https://bugzilla.redhat.com/show_bug.cgi?id=1725412 but perhaps it's best
> to revert this change

Yes, please.

> and move the gnome-keyring recommends to geary instead.

Or simply make geary not fail if that happens? (Sounds like the fix would be in
libsecret, but I didn't look at the details).

One of the great things about dbus ipc is that we can have a loose coupling
between packages. A program should never ever abort because some other dbus
service is not active.

> Any thoughts?

Alternatively, rich dependencies could be used somewhere: recommend
gnome-keyring only if gnome-shell is present or something like that.

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

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

2020-04-04 Thread updates

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  27  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-02f03affd4   
ansible-2.9.6-1.el8
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-2cb1029c5a   
okular-18.12.2-2.el8
  11  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-913d6d1779   
coturn-4.5.1.1-3.el8
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-98e8249e5c   
chromium-80.0.3987.162-1.el8


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

epel-rpm-macros-8-9
nohang-0.1-26.20200403git18f90d7.el8
python-tqdm-4.45.0-1.el8
suricata-5.0.2-2.el8

Details about builds:



 epel-rpm-macros-8-9 (FEDORA-EPEL-2020-dea4090509)
 Extra Packages for Enterprise Linux RPM macros

Update Information:

Add qt5_qtwebengine_arches to macros

ChangeLog:

* Fri Apr  3 2020 Troy Dawson  - 8-9
- Add i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 armv3l armv4b 
armv4l armv4tl armv5tl armv5tel armv5tejl armv6l armv6hl armv7l armv7hl 
armv7hnl aarch64 mips mipsel mips64el to macros




 nohang-0.1-26.20200403git18f90d7.el8 (FEDORA-EPEL-2020-ebc1a98f68)
 Highly configurable OOM prevention daemon

Update Information:

Update to latest version

ChangeLog:

* Fri Apr  3 2020 Artem Polishchuk  - 
0.1-26.20200403git18f90d7
- Update to latest git snapshot
* Mon Mar 23 2020 Artem Polishchuk  - 
0.1-25.20200323gitdaca5cc
- Update to latest git snapshot




 python-tqdm-4.45.0-1.el8 (FEDORA-EPEL-2020-117ad76a4d)
 Fast, Extensible Progress Meter

Update Information:

Update to 4.45.0

ChangeLog:

* Fri Apr  3 2020 Stephen Gallagher  - 4.45.0-1
- Update to 4.45.0
* Mon Feb 10 2020 Stephen Gallagher  - 4.42.1-1
- Update to 4.42.1
* Mon Feb 10 2020 Stephen Gallagher  - 4.41.1-1
- Update to 4.41.1
* Thu Jan 30 2020 Fedora Release Engineering  - 
4.37.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild




 suricata-5.0.2-2.el8 (FEDORA-EPEL-2020-1219d4aced)
 Intrusion Detection System

Update Information:

Add python3-pyyaml to resolve (#1818935)

ChangeLog:

* Fri Apr  3 2020 Jason Taylor  5.0.2-2
- Add python3-pyyaml to resolve (#1818935)

References:

  [ 1 ] Bug #1818935 - The Suricata package should require pythonX-pyyaml
https://bugzilla.redhat.com/show_bug.cgi?id=1818935


___
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 987118] perl-5.18: File handles modified with binmode ':unix' leak