[Bug 1773172] New: Update biber to work with the latest texlive update

https://bugzilla.redhat.com/show_bug.cgi?id=1773172 Bug ID: 1773172 Summary: Update biber to work with the latest texlive update Product: Fedora Version: 31 Status: NEW Component: biber Assignee: c...@m.fsf.org

Re: Modularity and the system-upgrade path

Le samedi 16 novembre 2019 à 08:37 +0100, Nicolas Mailhot a écrit : > > Sure, do some rpm fixing if necessary so the result feels less like a > kludge than %dist. But, don’t rely on an external framework to do > things for you instead of doing the necessary work (if any) at the > component format

Re: Modularity and the system-upgrade path

Le samedi 16 novembre 2019 à 03:38 +0100, clime a écrit : > > A true solution would be blending modularity into RPM. > > At build time as well as at installation time. > > I agree this would be the best. Basically, final > product of a module build should be an rpm. modulemd > file should be kind

Re: How to approve a review request ?

Hi I want to approve the review request of vimvi-qt, but this is my first offical review 8-( You need to set fedora-review+ flag. Click on "Show advanced fields" near the top of the bug, and flags should be visible in a drop-down menu on the right. Mufti, it's weird that your screenshot

[Test-Announce] Fedora 32 Rawhide 20191115.n.0 nightly compose nominated for testing

Announcing the creation of a new nightly release validation test event for Fedora 32 Rawhide 20191115.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

[EPEL-devel] Any plans for supporting multiple python3 versions in EPEL8?

I'm wondering if anyone can shed any light on possible roadmaps for transitioning to newer python 3.X in RHEL8/EPEL8. What we have now appears to be: A module for different pythonXY versions: python27 2.7 [d] common [d] Python programming language, version 2.7

Re: Modularity and the system-upgrade path

> A true solution would be blending modularity into RPM. > At build time as well as at installation time. I agree this would be the best. Basically, final product of a module build should be an rpm. modulemd file should be kind of a meta-spec file which can be built distributively and that

Re: Python 2 exodus is happening now

On 11/14/19 6:02 PM, Miro Hrončok wrote: orion   openmpi     python2-openmpi (→ PY2)   python-pycodestyle     python2-pycodestyle (→ PY2)   python-setuptools_scm     python2-setuptools_scm (→ PY2) These have been removed. Thanks for pushing the process forward. -- Orion Poplawski

Re: Modularity and the system-upgrade path

Petr Pisar wrote: > With your proposal Bugzilla packager would have to package Bugzilla > twice: as a normal package for default Perl 5.26 and as a module for Perl > 5.30. Then a user would have hard time to select the right combinations of > Perl and Bugzilla. It would double fork work pacakgers

Re: Modularity and the system-upgrade path

Przemek Klosowski via devel wrote: > so for one module with two versions, we will have 2 builds, for 2 > modules with two versions we'll have four builds, and in general for N > modules with M versions on average, we will have N^M builds? M^N actually. 1 module with M versions = M builds 2

Re: OpenMPI is flaky

On 11/15/19 3:07 PM, Christoph Junghans wrote: Hi, I was trying to bump the espresso package to v4.1.1 and came across multiple issues in the %check phase of the builds on Rawhide, F31 and EPEL8. On Rawhide and F31, some tests seem to receive an error in the MPI_INIT phase. Error: *** An error

[Bug 1772725] perl-HTTP-Date-6.04 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1772725 --- Comment #7 from Fedora Update System --- perl-HTTP-Date-6.04-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1772861] perl-Image-Sane-5 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1772861 --- Comment #7 from Fedora Update System --- perl-Image-Sane-5-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1772785] Upgrade perl-Devel-CheckLib to 1.14

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

[Bug 1769870] perl-Image-Sane-4-1.fc32 FTBFS: t/81_scanimage-perl.t test fails with sane-backends-1.0.28

https://bugzilla.redhat.com/show_bug.cgi?id=1769870 --- Comment #6 from Fedora Update System --- perl-Image-Sane-5-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1772056] perl-HTTP-Date-6.03 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1772056 --- Comment #12 from Fedora Update System --- perl-HTTP-Date-6.04-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1762233] [RFE] Please build for EPEL8

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

[Bug 1761852] perl-Email-Sender for EL8

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

Re: Intent to retire OCE (OpenCascade Community Edition)

On Fri, Nov 15, 2019 at 3:59 PM Ian McInerney wrote: > A repoquery for build-requires on the OCE-devel package only gives these 4 > packages: > gmsh-0:4.4.1-3.fc32.src > kicad-1:5.1.4-5.fc32.src > netgen-mesher-0:6.2.1810-4.fc32.src > smesh-0:6.7.5-7.fc31.src > > I know that switching KiCad to

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

The following Fedora EPEL 7 Security updates need testing: Age URL 458 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 199 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-c499781e80 python-gnupg-0.4.4-1.el7 197

[Bug 1772861] perl-Image-Sane-5 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1772861 --- Comment #6 from Fedora Update System --- perl-Image-Sane-5-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1772056] perl-HTTP-Date-6.03 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1772056 --- Comment #11 from Fedora Update System --- perl-HTTP-Date-6.04-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1772725] perl-HTTP-Date-6.04 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1772725 --- Comment #6 from Fedora Update System --- perl-HTTP-Date-6.04-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1769870] perl-Image-Sane-4-1.fc32 FTBFS: t/81_scanimage-perl.t test fails with sane-backends-1.0.28

https://bugzilla.redhat.com/show_bug.cgi?id=1769870 --- Comment #5 from Fedora Update System --- perl-Image-Sane-5-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See

[Bug 1772056] perl-HTTP-Date-6.03 is available

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

[Bug 1772725] perl-HTTP-Date-6.04 is available

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

[Bug 1772861] perl-Image-Sane-5 is available

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

[Bug 1769870] perl-Image-Sane-4-1.fc32 FTBFS: t/81_scanimage-perl.t test fails with sane-backends-1.0.28

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

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

On 2019-11-15 at 14:51 UTC, David Malcolm wrote: Thinking aloud: does anyone ever use symbol overriding for anything other than glibc? Yes. It is particularly useful for "spear fishing" debugging of lower-level interfaces in large, complex multi-process applications. By some means you

Re: Orphaning nm-tray

Raphael Groner wrote: > I'll orphan the package nm-tray due to not in active usage nor > development. > > Currently FTBFS: > https://bugzilla.redhat.com/show_bug.cgi?id=1754157 > > Please feel free to pick the package if you still think it's of any > usefulness in Fedora. I think it is of use

Re: What are the benefits of default modular streams over non-modular packages?

John M. Harris Jr wrote: > Python 2 and Python 3 are inherently incompatible, and many programs WILL > NOT be migrated to Python 3. In fact, we're simply dropping many packages, > some were even explicitly denied an exception, that refused to "upgrade" > to Python 3. Indeed. As much as I agree

Re: What are the benefits of default modular streams over non-modular packages?

Joe Orton wrote: > So it's clear to me that you see that packagers chosing default streams > over non-modular packages impose external costs on the rest of the > distro (packagers and/or users?) somehow. This thread was supposed to > focus on benefits, and these vague claims about costs and

Re: Modularity and the system-upgrade path

On 15. 11. 19 19:10, Petr Pisar wrote: Now you can think another modularity fatatic who wants to modularize everything and have all modules in multiple versions. Not at all. Don't worry, I don't consider anybody a modular fanatic. Yet anyway. Thanks for you answer, it has been valuable to me

Re: Minimization Objective report

Adam Samalik wrote: > 1/ A history chart for base images [2] is now being generated — includes > data since 25 September. It's a bit rough initial implementation, but it's > there! Almost 2 months of work to save… 0.5%! That does not look like a huge success to me. You simply cannot win against

Re: What are the benefits of default modular streams over non-modular packages?

On Friday, November 15, 2019 1:55:44 PM MST Alex Scheel wrote: > I do agree that we will need to migrate to JDK 11, but that'll take > time. Perhaps we need Miro's fine management skills and strict policy > enforcement to get us there a la python2->python3 migration. That's not the same, at all.

[EPEL-devel] Re: Recent epel 8 branchs - no tag of package in epel

On Thu, 2019-11-14 at 18:33 +, Paul Howarth wrote: > On Thu, 14 Nov 2019 15:08:32 +0100 > Steve Traylen wrote: > > > Hi, > > > > > > Last couple of days the epel8 branch requests have been processed > > okay. Thanks > > > > However when you then try and build something it results in > >

Orphaning nm-tray

Hi there, I'll orphan the package nm-tray due to not in active usage nor development. Currently FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=1754157 Please feel free to pick the package if you still think it's of any usefulness in Fedora. Regards, Raphael

OpenMPI is flaky

Hi, I was trying to bump the espresso package to v4.1.1 and came across multiple issues in the %check phase of the builds on Rawhide, F31 and EPEL8. On Rawhide and F31, some tests seem to receive an error in the MPI_INIT phase. Error: *** An error occurred in MPI_Init *** on a NULL communicator

[Bug 1772785] Upgrade perl-Devel-CheckLib to 1.14

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

Re: Intent to retire OCE (OpenCascade Community Edition)

A repoquery for build-requires on the OCE-devel package only gives these 4 packages: gmsh-0:4.4.1-3.fc32.src kicad-1:5.1.4-5.fc32.src netgen-mesher-0:6.2.1810-4.fc32.src smesh-0:6.7.5-7.fc31.src I know that switching KiCad to use opencascade instead should be simple (just switch a CMake flag),

[Bug 1773105] New: perl-HTTP-Cookies-6.07 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1773105 Bug ID: 1773105 Summary: perl-HTTP-Cookies-6.07 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTTP-Cookies Keywords: FutureFeature, Triaged

Re: Python 2 exodus is happening now

Rex Dieter wrote: > Miro Hrončok wrote: > >> Dear maintainers, >> here is an updated list of packages that (transitively, at build or run >> time) require Python 2 and have not yet requested a FESCo exception to do >> so. Packages with open exception requests have been excluded for now to >> be

[Bug 1773104] New: perl-DateTime-TimeZone-2.38 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1773104 Bug ID: 1773104 Summary: perl-DateTime-TimeZone-2.38 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-TimeZone Keywords: FutureFeature,

Re: Python 2 exodus is happening now

Rex Dieter wrote: > Miro Hrončok wrote: > >> Dear maintainers, >> here is an updated list of packages that (transitively, at build or run >> time) require Python 2 and have not yet requested a FESCo exception to do >> so. Packages with open exception requests have been excluded for now to >> be

Intent to retire OCE (OpenCascade Community Edition)

It has a lot of libraries so I haven't tried figuring out what all packages are affected but since OCC (OpenCASCADE) went GPL OCE has not been updated and appears to be no longer maintained. I have moved FreeCAD over to my new "opencascade" package and am working on moving netgen-mesher over.

Re: Python 2 exodus is happening now

Miro Hrončok wrote: > Dear maintainers, > here is an updated list of packages that (transitively, at build or run > time) require Python 2 and have not yet requested a FESCo exception to do > so. Packages with open exception requests have been excluded for now to be > able to finish the

Re: What are the benefits of default modular streams over non-modular packages?

- Original Message - > From: "Fabio Valentini" > To: "Development discussions related to Fedora" > > Sent: Friday, November 15, 2019 10:58:04 AM > Subject: Re: What are the benefits of default modular streams over > non-modular packages? > ~snipping long thread~ > Another issue is

Re: fatal error: x86intrin.h: No such file or directory

> Does it work in mock on non-x86? x86intrin.h is x86-specific header and won't > be present on other arches, but it looks like it's included unconditionally. Weill not exactly. gcc-trunk/trunk$ find ./ -name x86intrin.h ./gcc/config/i386/x86intrin.h ./gcc/config/rs6000/x86intrin.h PPC has

Re: Non-responsive maintainer: huwang?

On 2019-11-14 5:03 a.m., Fabio Valentini wrote: > Hi everybody, Hi Fabio, All the maven-*-plugin packages were related to the mvn command we used to maintain in Fedora to build Maven-based software. It was a modified maven that would use RPMs to provide the dependent artifacts.  We initially

[Bug 1761852] perl-Email-Sender for EL8

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

Re: How to approve a review request ?

On Fri, Nov 15, 2019 18:15:57 +0100, Alexander Ploumistos wrote: > On Fri, Nov 15, 2019 at 6:04 PM J. Scheurich wrote: > > > > Hi, > > >> I want to approve the review request of vimvi-qt, but this is my first > > >> offical review 8-( > > > You need to set fedora-review+ flag. Click on "Show

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

* David Malcolm: > What would it do to distro-wide performance if > -fno-semantic-interposition > were added to the default rpm build flags, (and glibc added -fsemantic- > interposition to override this)? glibc already does the equivalent of -fno-semantic-interposition manually. We even have

Re: Minimization Objective report

Adam Samalik writes: > This is the Minimization Objective [0] update. > > Status: Discovery phase > > == Next phase approval == > > Next phase proposal [1] is being voted on by the Council — only positive > votes so far! > > == Feedback Pipeline == > > A few new features developed! > > 1/ A

Re: Modularity and the system-upgrade path

On 2019-11-15, Miro Hrončok wrote: > On 15. 11. 19 16:11, Petr Pisar wrote: >> On 2019-11-15, Miro Hrončok wrote: >>> On 15. 11. 19 14:32, Petr Pisar wrote: On 2019-10-04, Miro Hrončok wrote: > Wouldn't it be easier if the "default stream" would just behave like > a regular

Re: Python 2 exodus is happening now

On 11/15/19 2:03 PM, Jared K. Smith wrote: On Fri, Nov 15, 2019 at 7:53 AM Miro Hrončok > wrote: No, it is not too late. Drop the dependency. I will delay the retirement until you do so (or until you stop responding). Dropping the dependency was much

Re: Modularity and the system-upgrade path

On 11/15/19 11:27 AM, Petr Pisar wrote: No. Modularity solves this combination problem with "stream expansion". Sources for such module exists only once, you submit them for building with fedpkg only once, but a build systems computes all combinations (this the stream expansion) and schedules a

Re: How to approve a review request ?

On Fri, Nov 15, 2019 at 6:04 PM J. Scheurich wrote: > > Hi, > >> I want to approve the review request of vimvi-qt, but this is my first > >> offical review 8-( > > You need to set fedora-review+ flag. Click on "Show advanced fields" near > > the top of the bug, and flags should be visible in a

Re: How to approve a review request ?

Hi, I want to approve the review request of vimvi-qt, but  this is my first offical review 8-( You need to set fedora-review+ flag. Click on "Show advanced fields" near the top of the bug, and flags should be visible in a drop-down menu on the right. I still don't find it 8-(

Re: fatal error: x86intrin.h: No such file or directory

On Thu, Nov 14, 2019 at 5:00 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > On Thursday, 14 November 2019 at 23:02, Richard Shaw wrote: > > The package is building fine in mock but when I try to do a scratch build > > I'm getting the following error: > > > > fatal error:

Re: Modularity and the system-upgrade path

On Fri, Nov 15, 2019, 17:38 Petr Pisar wrote: > On 2019-11-15, Daniel P Berrangé wrote: > > On Fri, Nov 15, 2019 at 02:53:08PM -, Petr Pisar wrote: > >> On 2019-11-15, John M. Harris Jr wrote: > >> > On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote: > >> >> Example: I have

Re: Modularity and the system-upgrade path

On 2019-11-15, Daniel P Berrangé wrote: > On Fri, Nov 15, 2019 at 02:53:08PM -, Petr Pisar wrote: >> On 2019-11-15, John M. Harris Jr wrote: >> > On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote: >> >> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an >> >>

Re: What are the benefits of default modular streams over non-modular packages?

On Fri, Nov 15, 2019 at 3:31 PM Joe Orton wrote: > > On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote: > > Where is the end-user benefit with the modular default stream? I don't see > > it either, sorry. Let me offer a second opinion (coming from some first-hand experience) here: >

Re: Modularity: The Official Complaint Thread

On 11/14/19 10:52 PM, Stephen Gallagher wrote: On Thu, Nov 14, 2019 at 4:49 PM Miro Hrončok > wrote: On 14. 11. 19 22:30, Stephen Gallagher wrote: > On Thu, Nov 14, 2019 at 4:24 PM Miro Hrončok mailto:mhron...@redhat.com>> wrote: > >> Easy is

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

On Fri, 2019-11-15 at 16:28 +0100, Miro Hrončok wrote: > On 15. 11. 19 16:20, Vít Ondruch wrote: > > Dne 15. 11. 19 v 15:51 David Malcolm napsal(a): > > > On Fri, 2019-11-15 at 12:31 +, Daniel P. Berrangé wrote: > > > > On Fri, Nov 15, 2019 at 01:23:09PM +0100, Miroslav Suchý wrote: > > > > >

Re: What are the benefits of default modular streams over non-modular packages?

On Fri, Nov 15, 2019 at 02:30:20PM +, Joe Orton wrote: > On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote: > > Where is the end-user benefit with the modular default stream? I don't see > > it either, sorry. > > It's not clear to me how those examples are related to my argument,

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

On 14. 11. 19 14:47, Miro Hrončok wrote: On 05. 11. 19 16:03, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/PythonStaticSpeedup == Summary == Python 3 traditionally in Fedora was built with a shared library libpython3.?.so and the final binary was dynamically linked against that

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

On Fri, Nov 15, 2019 at 09:51:45AM -0500, David Malcolm wrote: > On Fri, 2019-11-15 at 12:31 +, Daniel P. Berrangé wrote: > > On Fri, Nov 15, 2019 at 01:23:09PM +0100, Miroslav Suchý wrote: > > > Dne 15. 11. 19 v 10:21 Victor Stinner napsal(a): > > > > I'm not sure if we need a Fedora change

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

On 15. 11. 19 16:20, Vít Ondruch wrote: Dne 15. 11. 19 v 15:51 David Malcolm napsal(a): On Fri, 2019-11-15 at 12:31 +, Daniel P. Berrangé wrote: On Fri, Nov 15, 2019 at 01:23:09PM +0100, Miroslav Suchý wrote: Dne 15. 11. 19 v 10:21 Victor Stinner napsal(a): I'm not sure if we need a

Re: Modularity and the system-upgrade path

On Friday, November 15, 2019 7:53:08 AM MST Petr Pisar wrote: > Modularity can achieve it when both Perls are packaged as a module. I'm > only showing why we need default stream if we want modules. If that's the case, why not build a (separate) Modularity distro? If Modularity cannot work with

Re: Modularity and the system-upgrade path

On 15. 11. 19 16:11, Petr Pisar wrote: On 2019-11-15, Miro Hrončok wrote: On 15. 11. 19 14:32, Petr Pisar wrote: On 2019-10-04, Miro Hrončok wrote: Wouldn't it be easier if the "default stream" would just behave like a regular package? I can think of two solutions of that: 1. (drastic for

libdvdread SONAME bump

Hello, libdvdread 6.0.2 brings a SONAME bump from .so.4 to .so.7 due to a small change in the pgc_t struct (still_time and pg_playback_mode fields were swapped). Only dvdauthor and libdvdnav packages in Fedora and dvd95 package in RPM Fusion actually reference any of those fields, but it's still

Re: Modularity and the system-upgrade path

On Fri, Nov 15, 2019 at 02:53:08PM -, Petr Pisar wrote: > On 2019-11-15, John M. Harris Jr wrote: > > On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote: > >> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an > >> laternative version. Now I want to package

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

Dne 15. 11. 19 v 15:51 David Malcolm napsal(a): > On Fri, 2019-11-15 at 12:31 +, Daniel P. Berrangé wrote: >> On Fri, Nov 15, 2019 at 01:23:09PM +0100, Miroslav Suchý wrote: >>> Dne 15. 11. 19 v 10:21 Victor Stinner napsal(a): I'm not sure if we need a Fedora change just for a compiler

Re: Modularity and the system-upgrade path

On 2019-11-15, Miro Hrončok wrote: > On 15. 11. 19 14:32, Petr Pisar wrote: >> On 2019-10-04, Miro Hrončok wrote: >>> Wouldn't it be easier if the "default stream" would just behave like >>> a regular package? >>> >>> I can think of two solutions of that: >>> >>> 1. (drastic for modular

Re: I want build a RISC-V Fedora for supporting RV64IMAFD only not Compressed support

On Fri, Nov 15, 2019 at 4:07 PM Richard W.M. Jones wrote: > > On Fri, Nov 15, 2019 at 10:44:50AM +0530, Billa Surendra wrote: > > Dear Richard, > > > > I have booted Stage4 disk images > > on QEMU emulator, but > > it supporting compressed

Re: Modularity and the system-upgrade path

On 2019-11-15, John M. Harris Jr wrote: > On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote: >> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an >> laternative version. Now I want to package Bugzilla that's written in >> Perl. How do you package Bugzilla so that

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

On Fri, 2019-11-15 at 12:31 +, Daniel P. Berrangé wrote: > On Fri, Nov 15, 2019 at 01:23:09PM +0100, Miroslav Suchý wrote: > > Dne 15. 11. 19 v 10:21 Victor Stinner napsal(a): > > > I'm not sure if we need a Fedora change just for a compiler flag. > > > Again, the only drawback is that we will

Re: What are the benefits of default modular streams over non-modular packages?

On Fri, Nov 15, 2019 at 3:38 PM Joe Orton wrote: > > On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote: > > Where is the end-user benefit with the modular default stream? I don't see > > it either, sorry. > > It's not clear to me how those examples are related to my argument, > which I

Re: What are the benefits of default modular streams over non-modular packages?

On Fri, Nov 15, 2019 at 12:44:52PM +0100, Miro Hroncok wrote: > Where is the end-user benefit with the modular default stream? I don't see > it either, sorry. It's not clear to me how those examples are related to my argument, which I could summarize as: a) multiple module streams have a

Re: Something wrong with kernel-headers on fedora 30?

On Thu, Nov 14, 2019 at 6:20 PM Steven Munroe wrote: > > > kernel-headers is related to the userspace API and is not tied to a > > particular kernel version. > > If the userspace API doesn't change there's no need to rebuild. Is there a > > problem you're > > seeing by not having an updated

Re: Modularity and the system-upgrade path

On 15. 11. 19 14:32, Petr Pisar wrote: On 2019-10-04, Miro Hrončok wrote: Wouldn't it be easier if the "default stream" would just behave like a regular package? I can think of two solutions of that: 1. (drastic for modular maintainers) We keep miantaining the default versions of things as

Re: I want build a RISC-V Fedora for supporting RV64IMAFD only not Compressed support

On Fri, Nov 15, 2019 at 10:44:50AM +0530, Billa Surendra wrote: > Dear Richard, > > I have booted Stage4 disk images > on QEMU emulator, but > it supporting compressed instructions. I want Fedora Linux distro only for > supporting RV64IMAFD ,

Re: Modularity and the system-upgrade path

On 2019-10-07, Jaroslav Mracek wrote: > I would like to open discussions more widely, because we are talking about > future of software distribution and discussing only particular issue is not > an approach how to delivery solid and stable architecture. > > What issues I have in mind? > 1. Fedora

Re: Backend storage clean-up

Just quick (last) warning, we are going to delete the data on Monday morning. Pavel On Monday, September 30, 2019 1:37:33 AM CET Jakub Kadlcik wrote: > Hello, > > we have decided that it is a time to go through Copr backend data and > clean it up a little. Due to several bugs forgetting to

Re: Modularity and the system-upgrade path

On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote: > Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an > laternative version. Now I want to package Bugzilla that's written in > Perl. How do you package Bugzilla so that it works with Perl 5.26 as > well as with Perl

Re: Modularity and the system-upgrade path

On 2019-10-04, Miro Hrončok wrote: > Wouldn't it be easier if the "default stream" would just behave like > a regular package? > > I can think of two solutions of that: > > 1. (drastic for modular maintainers) > > We keep miantaining the default versions of things as ursine packages. > We only

[EPEL-devel] Re: hitch is broken in epel7, fix in fedora may or may not break production systems (bz #1731420)

Am 14.11.19 um 14:01 schrieb Leon Fauster: Am 13.11.19 um 20:44 schrieb Stephen John Smoogen: On Tue, 12 Nov 2019 at 17:06, Ingvar Hagelund wrote: Hello hitch is a TLS terminating network proxy, made to be lean and mean and do nothing else than terminating TLS. It fits hand-in-glove with

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

On 15. 11. 19 13:24, Aleksandra Fedorova wrote: Hi On Fri, Nov 15, 2019 at 10:22 AM Victor Stinner wrote: Hi Jan, With the helper of Florian Weimer and Charalampos Stratakis, we also agreed to test this flag in priority. I understood that it disables the LD_PRELOAD feature: it's no longer

CUPS 2.3.0 coming into rawhide

Hi all, after 2 years or so of solving licensing issue, I would like to announce CUPS-2.3.0 is going into Fedora rawhide next week. The 2.3.0 version brings several changes: _Change of license:_ It is Apache software license 2.0 with exceptions for LGPLv2 only and GPLv2 only now. ASL 2.0 is

Re: What are the benefits of default modular streams over non-modular packages?

On 15. 11. 19 14:03, Petr Pisar wrote: On 2019-11-14, Miro Hrončok wrote: I've asked whether it wouldn't be in fact much easier to keep the default versions of our packages non-modular. [...] Arguments were made that default modular streams are planned to deliver the exact same experience as

Re: What are the benefits of default modular streams over non-modular packages?

On Friday, November 15, 2019 6:03:40 AM MST Petr Pisar wrote: > You answered yourself: "default modular streams are planned to deliver > the exact same experience as non-modular packages." If they provide the > same experience, they provide the same set of benefits. Hence there > cannot be any

[Bug 1772875] Please branch and build perl-Text-Format for EPEL8

https://bugzilla.redhat.com/show_bug.cgi?id=1772875 Xavier Bachelot changed: What|Removed |Added Status|NEW |ASSIGNED Doc Type|---

Re: Python 2 exodus is happening now

On Fri, Nov 15, 2019 at 7:53 AM Miro Hrončok wrote: > No, it is not too late. Drop the dependency. I will delay the retirement > until > you do so (or until you stop responding). > Dropping the dependency was much easier than I had anticipated... I have dropped the Python2 dependency in

Re: What are the benefits of default modular streams over non-modular packages?

On 2019-11-14, Miro Hrončok wrote: > I've asked whether it wouldn't be in fact much easier to keep the > default versions of our packages non-modular. [...] > Arguments were made that default modular streams are planned to > deliver the exact same experience as non-modular packages, yet it was >

Re: How to approve a review request ?

On Fri, Nov 15, 2019 at 01:50:25PM +0100, J. Scheurich wrote: > Hi, > > I want to approve the review request of vimvi-qt, but  this is my first > offical review 8-( You need to set fedora-review+ flag. Click on "Show advanced fields" near the top of the bug, and flags should be visible in a

Re: How to approve a review request ?

Dne 15. 11. 19 v 13:50 J. Scheurich napsal(a): Hi, I want to approve the review request of vimvi-qt, but  this is my first offical review 8-( https://bugzilla.redhat.com/show_bug.cgi?id=1770278 I can't find the right page to do that. Can someone help me ?

Re: Python 2 exodus is happening now

Dne 15. 11. 19 v 13:37 Miro Hrončok napsal(a): however I don't think looking that back is worth it. I've seen a lot of people who were upgrading back from Fedora 1X. I am upgrading my notebook from F26. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

How to approve a review request ?

Hi, I want to approve the review request of vimvi-qt, but  this is my first offical review 8-( https://bugzilla.redhat.com/show_bug.cgi?id=1770278 I can't find the right page to do that. Can someone help me ? so long MUFTI ___ devel mailing list --

Re: Python 2 exodus is happening now

On 15. 11. 19 13:40, Jared K. Smith wrote: On Thu, Nov 14, 2019 at 8:03 PM Miro Hrončok > wrote: If you talked to us (on e-mail or Bugzilla) and think your package is fine as it is, but you don't have a FESCo exception (or a request for one), then there

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

- Original Message - > From: "Victor Stinner" > To: devel@lists.fedoraproject.org > Sent: Friday, November 15, 2019 10:21:44 AM > Subject: Re: Fedora 32 System-Wide Change proposal: Build Python 3 to > statically link with libpython3.8.a for better > performance > > Hi Jan, > > With

  1   2   >