Fedora-Cloud-33-20210701.0 compose check report

No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20210630.0): ID: 919600 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Self Introduction: Hangbin Liu

Hi, I'm Hangbin Liu, working at Red Hat Network Service Team. I maintain some networking downstream packages in RHEL. The current state of dropwatch[1] in fedora is Orphaned. But there are still some useful features that customer may like. So I'd like to take it first. I may take some other orphan

Re: Packager for hire - Was: Re: Additon to the repos - Kubectx + Kubens

Dne 30. 06. 21 v 18:34 Vitaly Zaitsev via devel napsal(a): Looks interesting. But who will pay for this job? Someone interested in such package in Fedora/EPEL. Be it person, small shop or large enterprise company. E.g. Several years ago, friend of mine wanted to have newer version of gdal fo

Fedora-Cloud-34-20210701.0 compose check report

No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20210630.0): ID: 919729 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://op

Re: Self Introduction: Hangbin Liu

On Thu, 2021-07-01 at 15:40 +0800, Hangbin Liu wrote: > Hi, Hi and welcome! > I'm Hangbin Liu, working at Red Hat Network Service Team. I maintain > some > networking downstream packages in RHEL. The current state of > dropwatch[1] in > fedora is Orphaned. But there are still some useful feature

[Fedocal] Reminder meeting : ELN SIG

Dear all, You are kindly invited to the meeting: ELN SIG on 2021-07-02 from 12:00:00 to 13:00:00 US/Eastern At fedora-meet...@irc.libera.net The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/9920/ ___ devel mailing

How to (better) deal with library major API changes

I'm still trying to figure out the best way to frame the problem and I don't have a specific solution in mind, but there's got to be a better solution for dealing with projects that make major API changes. Pre-side-tag this was even more difficult: 1. Make sure the new version builds 2. Maybe do s

Re: How to (better) deal with library major API changes

On 01. 07. 21 17:53, Richard Shaw wrote: 1. Create a compat or SOVERSION appended package (requires new review) Packages created so that multiple versions of the same package can coexist in the distribution does not require a new review: https://docs.fedoraproject.org/en-US/packaging-guideli

Re: How to (better) deal with library major API changes

On Thu, Jul 1, 2021 at 11:11 AM Miro Hrončok wrote: > On 01. 07. 21 17:53, Richard Shaw wrote: > > 1. Create a compat or SOVERSION appended package (requires new review) > > Packages created so that multiple versions of the same package can coexist > in > the distribution does not require a new r

Re: How to (better) deal with library major API changes

On 01. 07. 21 18:20, Richard Shaw wrote: On Thu, Jul 1, 2021 at 11:11 AM Miro Hrončok > wrote: On 01. 07. 21 17:53, Richard Shaw wrote: > 1. Create a compat or SOVERSION appended package (requires new review) Packages created so that multiple versions of

golang package review swap

Hello, I've submitted a few packages I need reviewed. I'm happy to swap if anyone has any pending reviews. 1) 1976038 - golang-github-sgreben-flagvar[1] 2) 1976041 - golang-github-peterbourgon-ff-3[2] 3) 1976414 - mqttcli[3] 1: https://bugzilla.redhat.com/show_bug.cgi?id=1976038 2: https://bugz

Re: How to (better) deal with library major API changes

Or, if I may be so bold— Convince the developers to use versioned symbols when they break the API/ABI. This is the 21st Century, and we have solutions for this. It's not rocket surgery. On Thu, Jul 1, 2021 at 11:55 AM Richard Shaw wrote: > I'm still trying to figure out the best way to fr

Re: Packager for hire - Was: Re: Additon to the repos - Kubectx + Kubens

Maybe I'm going a little OT, but speaking about hiring someone, as far as I understand it seems to me that Fedora project has an annual budget that is never fully spent: https://budget.fedoraproject.org/budget/docs/index.html I would rather like to see someone hired by Fedora to do full time main

Re: How to (better) deal with library major API changes

On Thu, Jul 1, 2021 at 12:35 PM Kaleb Keithley wrote: > > > Or, if I may be so bold— > > Convince the developers to use versioned symbols when they break the > API/ABI. > > This is the 21st Century, and we have solutions for this. It's not rocket > surgery. > > > That's actually not a problem

Re: Packager for hire - Was: Re: Additon to the repos - Kubectx + Kubens

On Thu, 1 Jul 2021 at 13:44, Mattia Verga via devel wrote: > > Maybe I'm going a little OT, but speaking about hiring someone, as far > as I understand it seems to me that Fedora project has an annual budget > that is never fully spent: > > https://budget.fedoraproject.org/budget/docs/index.html >

Re: Packager for hire - Was: Re: Additon to the repos - Kubectx + Kubens

On Thu, Jul 1, 2021 at 8:57 AM Miroslav Suchý wrote: > Hmm, this should be easy to implement. Just one wiki page. I created: > > https://fedoraproject.org/wiki/Packagers_for_hire > > Comments? Rather than a wiki for which people may not reliably curate (i.e. remove themselves) or respond to quer

Re: How to (better) deal with library major API changes

On Thu, Jul 01, 2021 at 12:52:51PM -0500, Richard Shaw wrote: > On Thu, Jul 1, 2021 at 12:35 PM Kaleb Keithley wrote: > > > > Or, if I may be so bold— > > Convince the developers to use versioned symbols when they break the API/ > ABI. > > This is the 21st Century, and we

FedoraRespin-34-updates-20210701.0 compose check report

No missing expected images. Failed openQA tests: 3/42 (x86_64) ID: 919857 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/919857 ID: 919877 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/91987

Re: Fedora Source-git SIG report #1 (June 2021)

On Fri, Jun 25, 2021, 8:52 AM Neal Gompa wrote: > On Fri, Jun 25, 2021 at 3:43 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Fri, Jun 25, 2021 at 03:49:23AM +, Dan Čermák wrote: > > > > > > > > > On June 24, 2021 9:22:51 PM UTC, "Miro Hrončok" > wrote: > > > >On 24. 06. 21 23:07, Miros

Re: building against epel8 modules

On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia wrote: > On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek wrote: > > > > > > > > On 6/22/21 7:08 PM, Stephen John Smoogen wrote: > > > > Welcome to RHEL-8 modularity and the joy it brings anyone trying to > > > port software to 8. The problem is not with

Re: building against epel8 modules

On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer wrote: > > > > On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia wrote: >> >> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek wrote: >> > >> > >> > >> > On 6/22/21 7:08 PM, Stephen John Smoogen wrote: >> >> > > Welcome to RHEL-8 modularity and the joy it brings

Re: building against epel8 modules

On Thu, Jul 1, 2021 at 11:24 PM Nico Kadel-Garcia wrote: > > On Thu, Jul 1, 2021 at 9:20 PM Josh Boyer wrote: > > > > > > > > On Wed, Jun 23, 2021, 4:58 AM Nico Kadel-Garcia wrote: > >> > >> On Tue, Jun 22, 2021 at 1:25 PM Jiri Vanek wrote: > >> > > >> > > >> > > >> > On 6/22/21 7:08 PM, Stephe

I would like to take dropwatch

Hi, The dropwatch package[1] was retired as Neil Horman left RedHat[2]. But the upstream status is still active[3]. Since this is still an useful feature (dump the dropped packets from kernel) for networking debugging. And there is no replace yet (bpftrace may replace it in future, but not now).

Re: building against epel8 modules

On Wed, Jun 23, 2021 at 8:58 AM Nico Kadel-Garcia wrote: > I can't find *anyone* who likes modularity. I like the concept of modules. But primarily only if someone else is doing the actual hard work that ends up being necessary to build them. ___ deve

Self Introduction: Shwetha K Acharya

I am Shwetha K Acharya. I work for Red Hat Gluster Storage team. I will be taking up packaging of selinux for gluster . Regards, Shwetha ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscrib