Re: Qt 5.14 rawhide

Hi, we recently did update to 5.13.2 which I think is enough for now. Main reason is that we need Plasma to properly work and Qt 5.12 and 5.13 are the only releases guaranteed to be compatible. There will definitely be people using upcoming Plasma version with Qt 5.14 so once it's properly test

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

So this just means that packages do not respect the environment. What about fixing them instead of trying to hack the environment? On Wed, Jan 8, 2020, 23:53 Tom Stellard wrote: > On 12/23/2019 11:59 AM, Tom Stellard wrote: > > On 12/21/2019 02:30 PM, Tomasz Kłoczko wrote: > >> > >> > >> On Sat,

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

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 still use gcc. I'm just not quite sure how to implement

Re: Copr Build System - review of 2019 and vote for features in 2020

On Wed, Jan 8, 2020 at 12:32 PM Iñaki Ucar wrote: > > On Wed, 8 Jan 2020 at 18:08, Neal Gompa wrote: > > > > * automatic rebuilds of packages when dependencies change > > But this doesn't even happen in Koji, right? Cross-repo is even more > challenging. Besides, this is only needed when there's

Re: Upgrading libffi

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 simple. Thanks for the tip! AG --

Re: Upgrading libffi

"Colin Walters" writes: > Anthony, I think all of the work you've done on libffi has been very valuable > to the FOSS community. It's good code that has gained widespread use in > critical projects such as glib, python, etc. Thanks Colin! > Which commit to libffi for aarch64 porting required

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

On 12/23/2019 11:59 AM, Tom Stellard wrote: > On 12/21/2019 02:30 PM, Tomasz Kłoczko wrote: >> >> >> On Sat, 21 Dec 2019 at 00:37, Neal Gompa > > wrote: >> [..] >> >> I believe it's also used by the %cmake and %meson macros. >> >> >> Yep. >> Look on the output of the

Re: koji / bodhi issues status update

On Wed, 2020-01-08 at 09:58 -0800, Kevin Fenzi wrote: > On Wed, Jan 08, 2020 at 04:48:54AM -0700, Brad Bell wrote: > > I do not understand the state of the following build: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178 > > > > When I attempt to resubmit it I get: > > cppad>fedpk

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

It would be in RedHat's own best interest to promote the Fedora project more though.  Isn't Fedora supposed to be the upstream/testing grounds for RHEL releases?  What's the best way to learn and get familiar with a RedHat based environment?  It's Fedora, although I do know RHEL offers free develop

Re: New Package Process

On Wed, Jan 8, 2020 at 10:26 PM Steve Dickson wrote: > > Hello, > > I have a new contributor who wants to get > a package into Fedora. > > The package is called "Flight Data Recorder" >https://github.com/oracle/fdr > > It manages ftraces to record kernel data in way, when > there is a kern

New Package Process

Hello, I have a new contributor who wants to get a package into Fedora. The package is called "Flight Data Recorder" https://github.com/oracle/fdr It manages ftraces to record kernel data in way, when there is a kernel crash, one can go back and "see" what happen... It sounds very pro

Re: Upgrading libffi

Hi, On Mon, Jan 6, 2020, at 6:11 PM, Anthony Green wrote: > > I released a new version of libffi a month or so ago, the first one in 5 > years. There's an ABI change that was unavoidable in order to > accommodate the aarch64 port, and the sonumber was bumped. Anthony, I think all of the work yo

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

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 just work for all workloads without > tuning. The last bits for this

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

On 1/7/20 10:28 AM, Matthew Miller wrote: On Tue, Jan 07, 2020 at 03:22:45PM +0100, Iñaki Ucar wrote: For me, the main challenge Fedora faces is **positioning**. Let me explain: (I don't have numbers but) in my (limited) experience, when seasoned sysadmins need to launch a new system, they usua

Re: Upgrading libffi

If you push changes to the dist-git, I can handle builds and rebuilds. On Wed, Jan 8, 2020, 19:58 Kevin Fenzi wrote: > On Tue, Jan 07, 2020 at 10:20:59AM -0500, Anthony Green wrote: > > Neal Gompa writes: > > > > > RPM does not use libffi at all. > > > > My bad.. rpmbuild, through it's use of g

Re: Upgrading libffi

On Tue, Jan 07, 2020 at 10:20:59AM -0500, Anthony Green wrote: > Neal Gompa writes: > > > RPM does not use libffi at all. > > My bad.. rpmbuild, through it's use of gdb, which requires python, which > requires libffi. So my naive use of mock to try to build a new version > of libffi and all of

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

"Colin Walters" writes: > On Tue, Jan 7, 2020, at 6:41 AM, Tom Hughes wrote: > >> I'd love to find a way to directly integrate the likes of gem, npm >> etc directly into our packaging rather than us having to repackage >> everything by hand but I just don't see any way of doing it without >> comp

Re: koji / bodhi issues status update

On Wed, Jan 08, 2020 at 04:48:54AM -0700, Brad Bell wrote: > I do not understand the state of the following build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178 > > When I attempt to resubmit it I get: > cppad>fedpkg build > Could not execute build: Package cppad-2020.0-1.fc31

Re: Copr Build System - review of 2019 and vote for features in 2020

On Wed, 8 Jan 2020 at 18:31, Iñaki Ucar wrote: > > * Task blocking based on dependencies per chroot. If I submit tasks > [A, B, C] and [B, C] depend on A, I want [B, C] blocked in "pending" > until A is successfully built. Maybe a couple of retries if A fails, > and then [B, C] should be skipped i

Re: Copr Build System - review of 2019 and vote for features in 2020

On Wed, 8 Jan 2020 at 18:08, Neal Gompa wrote: > > * automatic rebuilds of packages when dependencies change But this doesn't even happen in Koji, right? Cross-repo is even more challenging. Besides, this is only needed when there's a soname bump. Otherwise, it would be just a waste of resources.

Re: Copr Build System - review of 2019 and vote for features in 2020

On Wed, Jan 8, 2020 at 4:01 AM Miroslav Suchý wrote: > > * build Flatpak application from your project - we have a viable idea how to > build Flatpak app from your project with > just a few clicks, and we can upload the result to some registry. E.g., to > https://quay.io/ This is an interestin

Re: Copr Build System - review of 2019 and vote for features in 2020

Le 08/01/2020 à 10:00, Miroslav Suchý a écrit : * build Flatpak application from your project - we have a viable idea how to build Flatpak app from your project with just a few clicks, and we can upload the result to some registry. E.g., to https://quay.io/ If it works as I understand it, tha

Re: peek package

Il 08/01/20 08:09, Artem Tim ha scritto: > vokoscreenNG packaged now. Nice to have such app available in official repos. > > F31: https://bodhi.fedoraproject.org/updates/FEDORA-2020-a489a2436a > F30: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aa27dbce21 > __

Re: Re: koji / bodhi issues status update

I do not understand the state of the following build: https://koji.fedoraproject.org/koji/taskinfo?taskID=40063178 When I attempt to resubmit it I get: cppad>fedpkg build Could not execute build: Package cppad-2020.0-1.fc31 has already been built Note: You can skip this check with --skip-nvr-

Re: Copr Build System - review of 2019 and vote for features in 2020

On Wed, Jan 8, 2020, 12:19 Miroslav Suchý wrote: > Dne 08. 01. 20 v 11:15 Fabio Valentini napsal(a): > > How do I actually enable this? I can't find it, neither in the web > > interface, nor in copr-cli. > > It would be useful to have this set up for my elementary-nightly COPR, > > since there ar

Re: Copr Build System - review of 2019 and vote for features in 2020

Dne 08. 01. 20 v 11:15 Fabio Valentini napsal(a): > How do I actually enable this? I can't find it, neither in the web > interface, nor in copr-cli. > It would be useful to have this set up for my elementary-nightly COPR, > since there are 1+ builds in there, accumulated since 2015, and I > rea

[Bug 1788183] perl-POSIX-AtFork-0.04 is available

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

Re: Copr Build System - review of 2019 and vote for features in 2020

Dne 08. 01. 20 v 11:18 Dan Horák napsal(a): > if COPR can utilize remote (cloud) resources, I would concentrate on > such way. When we will know the requirements, we can work with our > partners to allocate them. Copr can use cloud. Or almost anything. We use OpenStack. We have AARCH64 builders i

Re: Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem

On Tue, 7 Jan 2020 at 18:07, Martin Kolman wrote: > IIRC the speedups in compression and decompression > speed we got for RPMs[0] with zstd were pretty nice If it helps the argument, at the moment 99.7% of the time building the AppStream metadata is spent decompressing the RPMs. If zstd helps wit

Re: Copr Build System - review of 2019 and vote for features in 2020

On Wed, 8 Jan 2020 10:00:07 +0100 Miroslav Suchý wrote: > I want to sum up what happened in Copr during 2019. At the end of > this email, you can see our TODO list and cast your vote on what we > should focus on. > > What are our plans for 2020? We have some mandatory tasks: > * migrate to new d

Re: Copr Build System - review of 2019 and vote for features in 2020

On Wed, Jan 8, 2020 at 10:01 AM Miroslav Suchý wrote: > > I want to sum up what happened in Copr during 2019. At the end of this email, > you can see our TODO list and cast your > vote on what we should focus on. Hi! Thanks for all this work, COPR is super useful. > During the year 2019: > > *

Re: Copr Build System - review of 2019 and vote for features in 2020

@all: Please note that "yes" is 1, on the left, in the form. I was casting wrong votes assuming 5 meant more votes for that option without actually reading it. @msuchy, @praiskup and the rest of the team: Thanks for the great work! Iñaki On Wed, 8 Jan 2020 at 10:08, Miroslav Suchý wrote: > > I

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

Dne 07. 01. 20 v 14:57 Iñaki Ucar napsal(a): > On Tue, 7 Jan 2020 at 13:28, Neal Gompa wrote: >> On Tue, Jan 7, 2020 at 7:04 AM Martin Kolman wrote: >>> On Tue, 2020-01-07 at 10:36 +0100, Vít Ondruch wrote: Dne 06. 01. 20 v 19:08 Nicolas Mailhot via devel napsal(a): > Le 2020-01-06 19:0

Re: Copr Build System - review of 2019 and vote for features in 2020

This is awesome. Also I've been dreaming for a long time to simplified and integrated this chain: Playing with package in Copr → Review Request package from Copr and import it to RHBZ in one click. This could save a lot of time and make easier maintainers life. SUSE already did something like th

Copr Build System - review of 2019 and vote for features in 2020

I want to sum up what happened in Copr during 2019. At the end of this email, you can see our TODO list and cast your vote on what we should focus on. During the year 2019: * we added native AARCH64 builders * we added emulated ARMhfp builders * released eight new versions of Mock including feat

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

* Matthew Miller: > On Tue, Jan 07, 2020 at 01:13:02PM +0100, Florian Weimer wrote: >> > In support of that, I'd like to also have that page steer people into >> > tooling for creating new spins —- and I'd like to see us invest in and >> > rebuild the spin creation processes. (Particularly, I'd li