Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

On 01/08/2020 11:28 PM, Miro Hrončok wrote: > On 08. 01. 20 23:47, Tom Stellard wrote: >> I suspect that if I can find some way to set the CC and CXX environment >> variables for all builds, not just ones using autoconf, cmake or meson, >> that might help cut down on the number of packages that

[Bug 1729976] Add perl-LWP-Protocol-connect to EPEL-7

https://bugzilla.redhat.com/show_bug.cgi?id=1729976 --- Comment #8 from Fedora Admin XMLRPC Client --- This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. -- You are receiving this mail because: You are on the CC list for the bug.

[389-devel] 389 DS nightly 2020-01-11 - 96% PASS

https://fedorapeople.org/groups/389ds/ci/nightly/2020/01/11/report-389-ds-base-1.4.3.0-20200111git49ccb4d.fc31.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

On Fri, Jan 10, 2020 at 12:52 PM Vít Ondruch wrote: > > > Dne 10. 01. 20 v 18:33 Fabio Valentini napsal(a): > > On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon wrote: >> >> Good Morning Everyone, >> >> This is not a new idea, it has been presented at flock last year and spoken >> about on this

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

On Fri, Jan 10, 2020 at 11:37 AM Pierre-Yves Chibon wrote: > > > The release field would need to be set by koji ignoring whatever is in the > spec > file. How do we want to do this? > - Based on dates? > - Using an always increasing integer? > - Using the number of successful builds since

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

On Fri, Jan 10, 2020 at 8:20 PM Michael Catanzaro wrote: > > On Fri, Jan 10, 2020 at 9:46 pm, Richard W.M. Jones > wrote: > > OpenSUSE proved years and years ago that dropping %changelog is > > possible, easy and desirable. We should do that IMHO. > > They still have %changelog at the bottom of

[Bug 1135626] perl-Clipboard: insecure temporary file usage [epel-7]

https://bugzilla.redhat.com/show_bug.cgi?id=1135626 --- Comment #3 from Fedora Update System --- perl-Clipboard-0.21-1.el7.1 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1789498] perl-Swim-0.1.48 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1789498 --- Comment #4 from Fedora Update System --- perl-Swim-0.1.48-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1135626] perl-Clipboard: insecure temporary file usage [epel-7]

https://bugzilla.redhat.com/show_bug.cgi?id=1135626 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|ON_QA --- Comment #2 from

[Bug 1789498] perl-Swim-0.1.48 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1789498 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

On Fri, Jan 10, 2020 at 9:46 pm, Richard W.M. Jones wrote: OpenSUSE proved years and years ago that dropping %changelog is possible, easy and desirable. We should do that IMHO. They still have %changelog at the bottom of each spec file, but as the last line of the file. The actual changelog

[EPEL-devel] Re: Software Collection packages for EPEL

Stephen John Smoogen wrote: On Wed, 8 Jan 2020 at 16:13, Stephen John Smoogen wrote: On Wed, 8 Jan 2020 at 16:07, Stephen John Smoogen wrote: On Wed, 8 Jan 2020 at 15:53, Dmitry Butskoy wrote: Considering how Firefox is built, I see it uses: devtoolset-8 rust-toolset-1.35 llvm-toolset-7.0

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

On Fri, Jan 10, 2020 at 2:05 AM Lennart Poettering wrote: > > On Mi, 08.01.20 12:24, Chris Murphy (li...@colorremedies.com) wrote: > > > On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering > > wrote: > > > > > > - facebook is working on making oomd something that just works for > > > everyone,

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

On-going related discussions on linux-mm@ list user space unresponsive, followup: lsf/mm congestion https://marc.info/?t=15784291223=1=2 Gist here is the kernel is working as expected. The process is asking for resources that don't exist and the kernel can't really assume either the workload

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

On Fri, Jan 10, 2020 at 05:36:46PM +0100, Pierre-Yves Chibon wrote: > Good Morning Everyone, > > This is not a new idea, it has been presented at flock last year and spoken > about on this very list this fall, so I'd like to push it a little further. > > Do we want to drop release and changelog

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

On Wed, Jan 8, 2020 at 8:25 PM Chris Murphy wrote: > > On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering > wrote: > > > > - facebook is working on making oomd something that just works for > > everyone, they are in the final rounds of canonicalizing the > > configuration so that it can

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

Le vendredi 10 janvier 2020 à 20:53 +0100, Fabio Valentini a écrit : > > You can never expect our tooling to do "magic" (TM) and work "just > right", no matter which Versions and Releases and Epochs of packages > are available from third-party repos and coprs. Yes, sure, but the current way we

Re: Let's talk about Fedora in the '20s!

On Tue, Jan 07, 2020 at 03:39:41PM +0100, Nicolas Mailhot via devel wrote: > It would be interesting to analyse all those things, not to plan an rpm > replacement, but to actually fix the things upstreams are not happy > about (and, a lot of time, those won't involve rpm, and when they do >

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

On Fri, Jan 10, 2020 at 6:36 PM Nicolas Mailhot via devel wrote: > > Le vendredi 10 janvier 2020 à 17:36 +0100, Pierre-Yves Chibon a écrit : > > Good Morning Everyone, > > > > This is not a new idea, it has been presented at flock last year and > > spoken > > about on this very list this fall, so

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

On Fri, Jan 10, 2020 at 6:52 PM Vít Ondruch wrote: > > > Dne 10. 01. 20 v 18:33 Fabio Valentini napsal(a): > > On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon wrote: >> >> Good Morning Everyone, >> >> This is not a new idea, it has been presented at flock last year and spoken >> about on this

Re: Let's talk about Fedora in the '20s!

On Wed, Jan 08, 2020 at 02:17:40PM -0500, John Florian wrote: > desired impact, but we should practice what we preach, at minimum: > make Fedora a selection for the OS in oVirt.  I wind up choosing the > latest RHEL for all my Fedora VMs but I always have to wonder if > that's optimal -- and I've

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Thu, Jan 09, 2020 at 12:16:17PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Additional_buildroot_to_test_x86-64_micro-architecture_update > > == Summary == > > Create a dedicated buildroot to test packages built with x86-64 > micro-architecture update. So, a few

Re: koji / bodhi issues status update

On Fri, 2020-01-10 at 08:03 +0100, Igor Gnatenko wrote: > No, that's not true. Anybody can tag their builds into a > f31-updates-candidate and such tags. I have to test it to see, ATM without stupid tests on production which I don't want to do, I can't test it. But if so, is less problematic .

[EPEL-devel] Re: Software Collection packages for EPEL

On Wed, 8 Jan 2020 at 16:13, Stephen John Smoogen wrote: > > On Wed, 8 Jan 2020 at 16:07, Stephen John Smoogen wrote: > > > > On Wed, 8 Jan 2020 at 15:53, Dmitry Butskoy wrote: > > > > > > Considering how Firefox is built, I see it uses: > > > devtoolset-8 > > > rust-toolset-1.35 > > >

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

Dne 10. 01. 20 v 18:33 Fabio Valentini napsal(a): > On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon > wrote: > > Good Morning Everyone, > > This is not a new idea, it has been presented at flock last year > and spoken > about on this very list this

Re: Upgrading libffi

On Fri, Jan 10, 2020 at 06:24:35AM -0500, Anthony Green wrote: > > Anthony Green writes: > > Kevin Fenzi writes: > >> I suppose you could also > >> add both old and new libffi source to the libffi package and build them > >> both (old to compat), rebuild in side tag and drop the old > >>

reiew request freewrl 4.0

Hi, I want to offer a review swap for freewrl 4.0: https://bugzilla.redhat.com/show_bug.cgi?id=1789919 /I would prefer C/C++ project to review. so long MUFTI / ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

Le vendredi 10 janvier 2020 à 17:36 +0100, Pierre-Yves Chibon a écrit : > Good Morning Everyone, > > This is not a new idea, it has been presented at flock last year and > spoken > about on this very list this fall, so I'd like to push it a little > further. > > Do we want to drop release and

[Bug 1789918] New: please build perl-Font-TTF-1.06 for EPEL 8

https://bugzilla.redhat.com/show_bug.cgi?id=1789918 Bug ID: 1789918 Summary: please build perl-Font-TTF-1.06 for EPEL 8 Product: Fedora EPEL Version: epel8 Status: NEW Component: perl-Font-TTF Assignee:

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon wrote: > Good Morning Everyone, > > This is not a new idea, it has been presented at flock last year and spoken > about on this very list this fall, so I'd like to push it a little further. > > Do we want to drop release and changelog from our spec

Re: What would it take to drop release and changelog from our spec files? (and do we want to?)

On Fri, 10 Jan 2020 at 17:45, Pierre-Yves Chibon wrote: > > With the changelog it becomes a little bit more tricky. > We currently have 3 changelogs in Fedora with 3 different target audience > (this > is how I understand them): > - One for the files in the git repository, meant to be

Intention to orphan python-slacker and slack-cleaner

Hi, as upstream created an already double forked fork called slack-cleaner2 [¹], I decided to orphan two of my python packages, both python-slacker (as a direct dependency) as well as slack-cleaner. Currently, slack-cleaner as in current repository isn't working for me any more, maybe due to

Spins keepalive deadline approaching

FESco previously approved a requirement that Spin/Labs owners send a keepalive request in order to keep building the spin or lab. I have opened Pagure issues[1] for all Spins and Labs listed on the wiki[2]. If you are the owner of one of those spins and labs, please reply in the appropriate

What would it take to drop release and changelog from our spec files? (and do we want to?)

Good Morning Everyone, This is not a new idea, it has been presented at flock last year and spoken about on this very list this fall, so I'd like to push it a little further. Do we want to drop release and changelog from our spec file? If we do, how would this work? The release field would need

[Bug 1729976] Add perl-LWP-Protocol-connect to EPEL-7

https://bugzilla.redhat.com/show_bug.cgi?id=1729976 --- Comment #7 from Fedora Admin XMLRPC Client --- This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. -- You are receiving this mail because: You are on the CC list for the bug.

Re: Ownership announce of retired package Pound

On Fri, 10 Jan 2020, Breno Brand Fernandes wrote: Hi all, Recently, I've sent an email on epel-dev regarding this ownership request[1]. So, somethings may be repeated for some of you (I'm sorry!). The package Pound was retired about a year ago. It failed to build and at that time the

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Fri, 2020-01-10 at 11:05 +0100, Florian Weimer wrote: > * Neal Gompa: > > > On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer wrote: > > > We do not want to change the RPM architecture, so that users still can > > > install third-party software. This means that we need to change the > > > dist

[EPEL-devel] Ownership announce of retired package Pound

Hi all, Recently, I've sent an email on epel-dev regarding this ownership request[1]. So, somethings may be repeated for some of you (I'm sorry!). The package Pound was retired about a year ago. It failed to build and at that time the maintainer didn't give any feedback on it[2]. Since then,

Ownership announce of retired package Pound

Hi all, Recently, I've sent an email on epel-dev regarding this ownership request[1]. So, somethings may be repeated for some of you (I'm sorry!). The package Pound was retired about a year ago. It failed to build and at that time the maintainer didn't give any feedback on it[2]. Since then,

Fedora rawhide compose report: 20200110.n.0 changes

OLD: Fedora-Rawhide-20200109.n.0 NEW: Fedora-Rawhide-20200110.n.0 = SUMMARY = Added images:1 Dropped images: 0 Added packages: 7 Dropped packages:2 Upgraded packages: 112 Downgraded packages: 0 Size of added packages: 12.94 MiB Size of dropped packages

[389-devel] please review: PR 50810 - Fix minor issues in lib389 healthcheck

https://pagure.io/389-ds-base/pull-request/50810 -- 389 Directory Server Development Team ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct:

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

Once upon a time, Aleksandra Fedorova said: > Similarly to what Josh said, we want to setup an environment for experiments. > It doesn't mean that things we experiment on are going to be merged in > Fedora. And it definitely doesn't mean that whatever we did in the > experimental environment can

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Fri, Jan 10, 2020 at 3:56 PM Chris Adams wrote: > > Once upon a time, Aleksandra Fedorova said: > > No. Afaik, the main reason the change was rejected is that we are not > > ready yet (or don't see yet the reason) for the update of the > > architecture. And the benefit of such an update is

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Fri, Jan 10, 2020 at 3:56 PM Chris Adams wrote: > > Once upon a time, Aleksandra Fedorova said: > > No. Afaik, the main reason the change was rejected is that we are not > > ready yet (or don't see yet the reason) for the update of the > > architecture. And the benefit of such an update is

Fedora-Rawhide-20200110.n.0 compose check report

No missing expected images. Compose FAILS proposed Rawhide gating check! 2 of 43 required tests failed, 9 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 6/155 (x86_64), 1/2 (arm) New failures (same test not failed in

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Fri, Jan 10, 2020 at 9:16 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jan 09, 2020 at 05:23:16PM -0500, Ben Cotton wrote: > > On Thu, Jan 9, 2020 at 5:03 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > 4. This certainly needs to be a "system wide change" with the related > > >

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

Once upon a time, Josh Boyer said: > As an experiment. To see if it actually has real, tangible benefit. I guess my biggest issue with it is the proposal does nothing to address the harm of the original proposal (namely, that Fedora would no longer support some brand-new hardware). To me, it

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Fri, Jan 10, 2020 at 9:13 AM Chris Adams wrote: > > Once upon a time, Josh Boyer said: > > I don't believe that is fair or even true. The premise of the new > > change is to allow alternative experimentation within Fedora proper > > without impacting the mainline distribution. There is no

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

Once upon a time, Aleksandra Fedorova said: > No. Afaik, the main reason the change was rejected is that we are not > ready yet (or don't see yet the reason) for the update of the > architecture. And the benefit of such an update is unclear. I disagree that that was the reason - the fact that

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

Hi, Chris, On Fri, Jan 10, 2020 at 2:37 PM Chris Adams wrote: > > Once upon a time, Aleksandra Fedorova said: > > The rejected change > > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update > > is explicitly referenced from the current one. So yes, it is the > > architecture

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

Once upon a time, Josh Boyer said: > I don't believe that is fair or even true. The premise of the new > change is to allow alternative experimentation within Fedora proper > without impacting the mainline distribution. There is no assumption > that the results will magically replace Fedora in

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Fri, Jan 10, 2020 at 8:37 AM Chris Adams wrote: > > Once upon a time, Aleksandra Fedorova said: > > The rejected change > > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update > > is explicitly referenced from the current one. So yes, it is the > > architecture update we

Re: This update's test gating status has been changed to, 'greenwave_failed'.

On Tue, Dec 24, 2019 at 12:45:25PM +0100, Ismael Olea wrote: >On Mon, Oct 7, 2019 at 9:44 AM Pierre-Yves Chibon <[1]pin...@pingoured.fr> >wrote: >  > > It likely was. Bodhi called greenwave to ask about a status of the > builds in an > update, greenwave calls Koji for

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

Once upon a time, Aleksandra Fedorova said: > The rejected change > https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update > is explicitly referenced from the current one. So yes, it is the > architecture update we are looking for. > > And I would suggest to avoid calling things

Re: Upgrading libffi

Anthony Green writes: > Kevin Fenzi writes: >> I suppose you could also >> add both old and new libffi source to the libffi package and build them >> both (old to compat), rebuild in side tag and drop the old >> sources/compat. >> Does that make sense? > > I like this idea because it seems

Re: Let's talk about Fedora in the '20s!

On Tue, Jan 7, 2020 at 1:51 PM Miro Hrončok wrote: > > For me, an ultimate success would be if upstream projects would actually use > Fedora-family distros in their CI testing. And I don't mean that they would > use > Copr or packit to package RPM packages, or that they deploy their own Jenkins

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Fri, Jan 10, 2020 at 5:05 AM Florian Weimer wrote: > > * Neal Gompa: > > > On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer wrote: > >> > >> We do not want to change the RPM architecture, so that users still can > >> install third-party software. This means that we need to change the > >> dist

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

* Neal Gompa: > On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer wrote: >> >> We do not want to change the RPM architecture, so that users still can >> install third-party software. This means that we need to change the >> dist tag to avoid confusion. >> > > Changing the RPM architecture does not

[Bug 1789636] perltidy-20200110 is available

||perltidy-20200110-1.fc32 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-01-10 09:51:23 --- Comment #2 from Paul Howarth --- Build done

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Fri, Jan 10, 2020 at 4:28 AM Florian Weimer wrote: > > We do not want to change the RPM architecture, so that users still can > install third-party software. This means that we need to change the > dist tag to avoid confusion. > Changing the RPM architecture does not necessarily mean that

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

Le ven. 10 janv. 2020 à 10:29, Florian Weimer a écrit : > > * Neal Gompa: > > > 1. Our builder resources are squeezed enough as it is. In doing this, > > are we going to get more machines so that we can have more builders? > > Between modules and this, I worry our resources will get squeezed far

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

* Neal Gompa: > 1. Our builder resources are squeezed enough as it is. In doing this, > are we going to get more machines so that we can have more builders? > Between modules and this, I worry our resources will get squeezed far > too tightly for my comfort. Please send me the required hardware

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

Hi, Neal, On Thu, Jan 9, 2020 at 10:01 PM Neal Gompa wrote: > > On Thu, Jan 9, 2020 at 12:17 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Additional_buildroot_to_test_x86-64_micro-architecture_update > > > > == Summary == > > > > Create a dedicated buildroot to test

[Bug 1789498] perl-Swim-0.1.48 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1789498 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version|

Re: Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM

On Mi, 08.01.20 12:24, Chris Murphy (li...@colorremedies.com) wrote: > On Mon, Jan 6, 2020 at 11:09 AM Lennart Poettering > wrote: > > > > - facebook is working on making oomd something that just works for > > everyone, they are in the final rounds of canonicalizing the > > configuration so

Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

On Thu, Jan 09, 2020 at 05:23:16PM -0500, Ben Cotton wrote: > On Thu, Jan 9, 2020 at 5:03 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > 4. This certainly needs to be a "system wide change" with the related > >additional info required for such changes. We certainly need releng > >to sign