Re: Handling --enable-experimental-jit in Python 3.13

On Wed, Apr 10, 2024 at 8:23 PM Miro Hrončok wrote: > Hello Pythonistas, > > Python 3.13 has an experimental JIT compiler: > > https://docs.python.org/dev/whatsnew/3.13.html#experimental-jit-compiler > > Enabling it is a configure (hence build-time) option. > > How do we handle this in Fedora? >

Re: Fedora Linux 40 Final Freeze

On Tue, Apr 2, 2024 at 12:39 PM Jakub Jelinek wrote: > sting->stable marked updates be still included in > stable without having to go through the exception/blocker process? > I was told there would be one more stable push at the releng channel on matrix. -- Best regards / S pozdravem,

Re: exiv2 and protobuf hard to do soname bump without turbulence

On Sat, Feb 10, 2024, 01:50 Sérgio Basto wrote: > "In order to update Exiv2, we need to know if this is okay to enable > BMFF support. Patents have theorically expired and it is enabled by > default in the latest version." > > until isn't clear by legal it should be disabled , if default is

Re: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

On Fri, Feb 9, 2024 at 2:16 AM Sérgio Basto wrote: > MLT built [1] (with one workaround for GCC for x86_64). > > [1] > https://bodhi.fedoraproject.org/updates/FEDORA-2024-7b5199d4f6 > > Thanks a lot, krita rebuilt: https://bodhi.fedoraproject.org/updates/FEDORA-2024-324af7694e -- Best regards

Re: [rawhide] libjpeg-turbo soname bump

at 5:15 PM Frantisek Zatloukal wrote: > In a few days, I'll start with bumping libjpeg-turbo in rawhide from 2.1.4 > to 3.0.2 ( https://src.fedoraproject.org/rpms/libjpeg-turbo/pull-request/2 > ). > > soname bump (0.2.0 to 0.3.0) is just for the turbojpeg consumers, libjpeg >

Re: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

On Tue, Feb 6, 2024 at 3:55 PM Sérgio Basto wrote: > On Tue, 2024-02-06 at 15:43 +0100, Frantisek Zatloukal wrote: > > > > > > On Tue, Feb 6, 2024 at 1:50 PM Sérgio Basto > > wrote: > > > Mass rebuild finished and merge to rawhide [1]. > > > Package

Re: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

On Tue, Feb 6, 2024 at 1:50 PM Sérgio Basto wrote: > Mass rebuild finished and merge to rawhide [1]. > Packages player and MLT are already FTBFS on Rawhide so I didn't touch > them . mlt is now FTI, do you plan to introduce opencv-compat to resolve that? -- Best regards / S pozdravem,

[rawhide] libjpeg-turbo soname bump

In a few days, I'll start with bumping libjpeg-turbo in rawhide from 2.1.4 to 3.0.2 ( https://src.fedoraproject.org/rpms/libjpeg-turbo/pull-request/2 ). soname bump (0.2.0 to 0.3.0) is just for the turbojpeg consumers, libjpeg so stays the same - API and ABI compatible, it's a drop-in

Re: [rawhide] libavif soname bump

libavif-1.0.3 built in f40-build-side-82609. Proceeding with rebuilds... On Thu, Jan 25, 2024 at 11:37 AM Frantisek Zatloukal wrote: > > > On Thu, Jan 25, 2024 at 11:23 AM Richard W.M. Jones > wrote: > >> On Thu, Jan 25, 2024 at 11:14:04AM +0100, Frantisek Zatloukal wrote:

Re: poppler soname bump in Rawhide soon

Also, at least efl is FTBFS now, so it can't be rebuilt, and you'll have to make a poppler-compat package before merging this, if efl isn't fixed by then. On Tue, Jan 30, 2024 at 2:03 PM Sandro wrote: > On 30-01-2024 12:15, Michael J Gruber wrote: > > Marek Kasik venit, vidit, dixit 2024-01-30

Re: [rawhide] libavif soname bump

On Thu, Jan 25, 2024 at 11:23 AM Richard W.M. Jones wrote: > On Thu, Jan 25, 2024 at 11:14:04AM +0100, Frantisek Zatloukal wrote: > > In about a week (after mass rebuild before branching), I'll start > > with bumping libavif in rawhide from 0.11.x to 1.0.3 > > ( https://

[rawhide] libavif soname bump

In about a week (after mass rebuild before branching), I'll start with bumping libavif in rawhide from 0.11.x to 1.0.3 ( https://src.fedoraproject.org/rpms/libavif/pull-request/2 , soname bump from 15 to 16). If I am not missing anything, it should mean ABI-only change, so all the dependencies

Heads up: Flask and Werkzeug 3.0

I have been working on the Pull Requests for Flask and Werkzeug rebases from 2.2.x versions to the 3.x in Fedora Rawhide. I am using the Werkzeug PR as the base one to post comments. Impact check is in the first comment: https://src.fedoraproject.org/rpms/python-werkzeug/pull-request/16# These

Re: Looking for a volunteer to automate the orphaned packages process

On Thu, Oct 19, 2023 at 6:24 PM Adam Williamson wrote: > I'm not sure I have time to take this, but glancing over it, I have a > suggestion on how to further automate the release stuff. > > You can use Bodhi release date to determine the extant EPEL releases > and the current Branched release.

Re: Can we squeeze coreutils-9.4 into Fedora 39?

On Wed, Aug 30, 2023 at 6:11 PM David Cantrell wrote: > I personally agree that this is enough of a change to warrant > consideration for Fedora 39, but I want Fedora QA to weigh in. At this > point we have beta and final blockers and you can use this form to > propose one: > >

Re: packager-dashboard not updating koschei build status

Hey, Thanks for raising the issue. It has been addressed and all the dashboards should now contain up2date data from koschei. Longer answer: The problem was the enablement of EPEL 9 Next in koschei, oraculum (the backend for the Packager Dashboard) isn't ready for these kinds of releases and I

Re: DNF5-5.0.1 has a stable API

On Thu, Jul 20, 2023 at 11:58 AM Peter Robinson wrote: > On Thu, Jul 20, 2023 at 10:46 AM Miroslav Suchý wrote: > > "Only dead projects has stable API" > > You can evolve APIs with versioning to ensure backwards compatibility > while also evolving the usecases. > Well, this is exactly the

Re: [rawhide] ICU upgrade to 73.2

The side tag has been merged: https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c -- Best regards / S pozdravem, František Zatloukal Senior Quality Engineer Red Hat ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe

Re: [rawhide] ICU upgrade to 73.2

On Thu, Jul 13, 2023 at 8:28 AM Remi Collet wrote: > Hi, > > Le 12/07/2023 à 10:15, Frantisek Zatloukal a écrit : > > I'd submitted the side-tag for merging to f39 base: > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c > > <https://bodhi.fedorap

Re: [rawhide] ICU upgrade to 73.2

FYI, postponing this to tomorrow, qt6 packages are unbuildable in rawhide (unrelated to this change). On Wed, Jul 12, 2023 at 10:33 AM Mamoru TASAKA wrote: > Frantisek Zatloukal wrote on 2023/07/12 17:18: > > On Wed, Jul 12, 2023 at 8:36 AM Mamoru TASAKA > > > wr

Re: [rawhide] ICU upgrade to 73.2

On Wed, Jul 12, 2023 at 8:36 AM Mamoru TASAKA wrote: > I am not the maintainer of brltty, but just adding "BR: gcc" makes > brltty compile on all arches (against f39): > https://koji.fedoraproject.org/koji/taskinfo?taskID=103255038 > > I am not sure to what side-tag I should build brltty for

Re: [rawhide] ICU upgrade to 73.2

I'd submitted the side-tag for merging to f39 base: https://bodhi.fedoraproject.org/updates/FEDORA-2023-18495e9c7c There are a bunch of packages missing, these will be handled after the side merge. If I didn't miss anything, all of the failures were FTBFS already. Since we have libicu72 in the

Re: [rawhide] ICU upgrade to 73.2

On Tue, Jul 11, 2023 at 11:06 PM Richard W.M. Jones wrote: > Yes I think it's better if you could proceed with brltty. > > Note I pushed a commit earlier today which excludes %{ix86} from the > OCaml subpackage. In OCaml 5 / Fedora 39 we are going to drop support > for this architecture

Re: [rawhide] ICU upgrade to 73.2

On Tue, Jul 11, 2023 at 10:56 PM Richard W.M. Jones wrote: > I think the OCaml build will take a while. > > Is this related to the (concurrent) Perl rebuild? > No, the perl rebuild is separate from this. There shouldn't be any overlap, afaik? In such case, I guess I should: - proceed with

Re: [rawhide] ICU upgrade to 73.2

On Tue, Jul 11, 2023 at 10:41 PM Jerry James wrote: > > It looks like we haven't gotten to brltty yet in the OCaml builds. > How long do you think it would be before you could merge your side > tag? If it won't be long, maybe we should wait for you. > > CCing Richard Jones, who is actually

Re: [rawhide] ICU upgrade to 73.2

On Tue, Jul 11, 2023 at 9:47 PM Jerry James wrote: > > brltty > > This package is also being built in a side tag for the OCaml 5.0.0 > update, which is already ongoing. Can you wait until the OCaml builds > are done to build this one? Otherwise, we're going to rebuild this > poor package over

[rawhide] ICU upgrade to 73.2

Hi, Later today, I'll be starting with rebuilds of packages depending on icu. The rebuilds will take place in f39-build-side-69764 for all packages returned by repoquery --whatrequires 'libicu*.so.72()(64bit)' (list cleaned up, converted to source package names, attached at the end of the

Re: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

On Thu, Jul 6, 2023 at 9:58 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 06/07/2023 21:32, Michael Catanzaro wrote: > > As explained in the proposal document, we know that opt-in metrics are > > not very useful because few users would opt in, and these users would > >

Re: How to use llvm15 for building a package

On Wed, Jul 5, 2023 at 3:25 AM Luya Tshimbalanga wrote: > I confirm I run the same issue once I properly set parameters for building > on cmake ( -DLLVM_ROOT=%{_libdir}/llvm15 \ >-DLLVM_BC_GENERATOR='clang++' \). > I am not sure this is what you'd want to do anyway as you'll be mixing

Re: [HEADS UP] Fedora 39 Python 3.12 rebuilds to start in a side tag this week

On Tue, Jun 27, 2023 at 8:44 PM Tomáš Hrnčiar wrote: > python-redis cicku kevin maxamillion > I've filled https://src.fedoraproject.org/rpms/python-redis/pull-request/13 , that should get python-redis going and unstuck a bunch of packages depending on it. Just a note, the failure

Re: disabling yum modular repos by default?

On Tue, May 9, 2023 at 2:22 PM Petr Pisar wrote: > I measured cached "dnf upgrade" (i.e. DNF4) on rawhide without and with > the modular > repository 5 times and the times are 1.022 vs. 1.090 seconds. I.e. 6.2% > speedup. > Just a note here that the speedup might be a bit larger on released

Re: z3 soname bump

On Mon, Jan 16, 2023 at 3:31 PM Lukas Zaoral wrote: > Hi, > there is no need to wait for klee. Unfortunately, the package cannot be > build > in Rawhide at the moment since the project cannot be built with LLVM 15 and > the llvm14 compatibility package cannot be used with clang 15 (and clang14 >

Re: HEADS UP: icu 72 coming to rawhide

On Sat, Dec 31, 2022 at 2:30 PM Pete Walter wrote: > This is now done. The following 4 packages failed to rebuild. The rest of > 102 packages built fine and are all rebuilt in rawhide. > > mozjs78: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691022 > mozjs91:

duktape soname bump

I wish I could write that I am going to build duktape 2.7.0 which bumps the soname. However, my brain kind of misfired and I didn't, for some reason, announce this upfront. The changes are minor, ABI changing stuff, I've taken care of rebuilding all the dependencies (main maintainers of those are

Re: Small rant: installer environment size

On Mon, Dec 12, 2022 at 1:25 PM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > If Intel ships all these blobs in linux-firmware, then they have a good > reason for this, don't they? > So newer linux-firmware can support older kernels, which isn't relevant for Fedora (to a

Re: wlroots 0.16 update announcement

>From gamescope perspective, a new release would require wlroot 0.16 (commit is already present in master), so can you cc me whenever you do wlroot 0.16 in bodhi? I'd either backport the specific commit/or a new release and add it to the update. I'll handle rawhide when we have a new release or

Re: Can we retire mozjs68 in rawhide?

Thanks for trying, fired off the build for real, passed too, mozjs68 retired from rawhide. I'll add it to fedora-obsolete-packages too. On Tue, Nov 29, 2022 at 12:20 PM Florian Weimer wrote: > * Frantisek Zatloukal: > > > Hey, > > > > yeah, I am looking forward to thr

Re: Can we retire mozjs68 in rawhide?

Hey, yeah, I am looking forward to throwing it away, erlang-js was changed ( https://github.com/erlang-mozjs/erlang-mozjs/issues/6 ) to be built against the new mozjs, but the build has failed, so repos still contain the old version ( https://koji.fedoraproject.org/koji/buildinfo?buildID=2085927

Mesa in F37- vaapi support disabled for h264/h265/vc1

Hi, since this mesa change ( https://src.fedoraproject.org/rpms/mesa/c/94ef544b3f2125912dfbff4c6ef373fe49806b52?branch=rawhide ) in F37 and rawhide, the mesa package lost support for vaapi accelerated encoding and decoding of h264, h265 and decoding of vc1 (

Re: The R stack in Rawhide is on fire

Huge thanks to everybody who'd helped with resolving this! I am deeply sorry about the issues I'd caused, this was the first time I was rebuilding a bunch of packages in a side-tag and merging it back and I didn't realize that this is something I should be cautious about. I'll watch out for this

Re: [rawhide] ICU upgrade to 71.1

/brltty-6.5-5.fc37.i386/usr/lib/brltty/libbrlapi_java.so File not found: /builddir/build/BUILDROOT/brltty-6.5-5.fc37.i386/usr/lib/java/brlapi.jar On Tue, Aug 2, 2022 at 4:04 PM Stephen Gallagher wrote: > On Mon, Aug 1, 2022 at 6:04 PM Frantisek Zatloukal > wrote: > > > > >

Re: [rawhide] ICU upgrade to 71.1

On Mon, Aug 1, 2022 at 7:46 PM Stephen Gallagher wrote: > On Mon, Aug 1, 2022 at 5:20 AM Frantisek Zatloukal > wrote: > > > > Hi, > > > > Later today, I'll be starting with rebuilds of packages depending on > icu. The rebuilds will take place in f37-build-side-

Re: Announcing fmt library soversion bump

On Wed, Jul 20, 2022 at 4:24 PM Mamoru TASAKA wrote: > Vitaly Zaitsev via devel wrote on 2022/07/11 2:43: > 0ad FTBFS on f37 due to different issue from fmt change - scratch build > for F-37 shows virtualenv related > issue - perhaps due to python3.11 changes, and scratch build for F-36 > shows

[rawhide] ICU upgrade to 71.1

Hi, Later today, I'll be starting with rebuilds of packages depending on icu. The rebuilds will take place in f37-build-side-55935 for all packages returned by sudo repoquery --whatrequires 'libicu*.so.69()(64bit)' (list attached at the end of the message). Please, if you're going to make

Heads up: python-redis 4.2.1

I am planning to build a new python-redis version in Rawhide/f37 ( https://src.fedoraproject.org/rpms/python-redis/pull-request/7# ). The current f37 build 3.5.3 is pretty old. The upstream does a good job of writing changelogs for anyone interested/affected:

Re: Action Required: Bugzilla - API Authentication changes

On Wed, Feb 9, 2022, 07:44 Mattia Verga via devel < devel@lists.fedoraproject.org> wrote: > So, I've updated review-stats container to run on F34 with > python-bugzilla 3.2.0, but it still authenticate using > username+password. Is that enough to avoid authentication errors and > user ban or I

Re: gcc-12.0.0-0.4.fc36 in rawhide

So, going over FTBFS bugs I've seen against bunch of my packages since the mass rebuild, there is bunch of "undefined reference to `std::type_info::operator==(std::type_info const&) const'" returned by ld, affecting only armv7hl arch. The affected packages are: mozjs68, mozjs78, mozjs91. I've

Re: gcc-12.0.0-0.4.fc36 in rawhide

On Tue, Jan 18, 2022 at 12:25 PM Jonathan Wakely wrote: > PR sent: > https://github.com/intel/intel-graphics-compiler/pull/226 > Thanks! Added a comment to that, works flawlessly! -- Best regards / S pozdravem, František Zatloukal Quality Engineer Red Hat

Re: gcc-12.0.0-0.4.fc36 in rawhide

On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek wrote: > If there are bugs on the compiler side, please let me know immediately, > so that those bugs can be fixed before the mass rebuild next week. > While I was trying to rebuild some Intel components, i've encountered this issue, which seems to

Re: Rawhide builds failing for a while now

So, it seems it didn't come to my mind that builders might not have new enough rpm to use rpm.open() which is available since rpm 4.17.0. A fix for it ( https://src.fedoraproject.org/rpms/authselect/pull-request/15# ) has been merged, old authselect untagged, the new build of authselect should

Re: Rawhide builds failing for a while now

On Tue, Dec 28, 2021 at 5:58 PM Ian McInerney via devel < devel@lists.fedoraproject.org> wrote: > That is a different error during the transaction. The original warning I > mentioned is in dbus-broker, and is only a warning (the RPM transaction > continues with no error). The other two you have

Re: Voluntarily step back as co-maintainer?

On Wed, Nov 24, 2021 at 11:58 AM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > Try removing yourself from ACL, i.e.: > 1. Go to https://src.fedoraproject.org/rpms/glabels and login > 2. Click on Settings tab > 3. Click on Users & Groups > 4. Click on the red "trash" icon next

Re: Firefox Hardware acceleration & VA-API how-to

On Fri, Nov 12, 2021, 11:08 Florian Weimer wrote: > Why is libva-intel-driver not part of Fedora? > > Thanks, > Florian > There are licensing / patent issues with the Intel driver. I am slowly progressing with packaging the latest intel-media-driver (not the older libva-intel-driver, and freed

Re: [Qa-tools-sig] Orphaned packages looking for new maintainers​

On Mon, Nov 8, 2021 at 4:53 PM Miro Hrončok wrote: > > python-pylibmcabompard, orphan, pjp1 weeks > ago > Taken. -- Best regards / S pozdravem, František Zatloukal Quality Engineer Red Hat ___ devel mailing list --

Re: API endpoint listing ISOs and checksums for Fedora releases and Rawhide?

Hi, in testcloud ( https://pagure.io/testcloud/blob/master/f/testcloud/util.py#_100 ), I am using adam's openqa nightlies.json for rawhide/branched: https://openqa.fedoraproject.org/nightlies.json (this isn't a "stable api") and https://getfedora.org/releases.json for stable releases. For

Fedora Packager Dashboard - Contextual Package Calendars and more!

Hi, In the past months, we've enabled "Contextual Package Calendars" on Fedora Packager Dashboard . In short, it shows you package-specific calendars, eg. If you maintain some GNOME package, the Dashboard will show you the GNOME release schedule.

Re: F35 mass rebuild is finished

On Fri, Jul 30, 2021, 16:12 Florian Weimer wrote: > Does this change only impact source packages which use the %cmake3 > macro, or potentially more packages? > I've seen a similar failure with wine-dxvk Fedora package, which uses meson/ninja. > ___

Re: x86_64-v2 in Fedora

On Wed, Jun 16, 2021 at 2:20 PM Florian Weimer wrote: > On Fedora 34 or later, you can use “/lib64/ld-linux-x86-64.so.2 --help”. > If x86-64-v2 shows up as “supported”, there is compatibile: > > | Subdirectories of glibc-hwcaps directories, in priority order: > | x86-64-v4 > | x86-64-v3

Planned Outage - Blockerbugs - 2021-05-18 17:00 UTC

There will be an outage starting at 2021-05-18 17:00UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-05-18 17:00UTC' Reason for outage: Host upgrade from Fedora 32 to Fedora

Planned Outage - Blockerbugs - 2021-05-18 17:00 UTC

There will be an outage starting at 2021-05-18 17:00UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-05-18 17:00UTC' Reason for outage: Host upgrade from Fedora 32 to Fedora

Re: selinux-policy package versioning change

On Wed, Mar 31, 2021 at 9:04 AM Zdenek Pytela wrote: > The freeze is on Tuesday, the plan is Monday, or after GA if it fails for > some reason. > Beware that bodhi is active for Fedora 34, so the update would need to receive necessary karma to be actually pushed before the freeze (I think the

Fedora Packager Dashboard - Available for wide use to all packagers

Hi, We'd like to announce that the Fedora Packager Dashboard passed the testing period, was properly deployed inside Fedora Infrastructure, got fixes, improvements and feature additions and is now available for widespread use among all Fedora Packagers. For those of you who didn’t hear about the

Fedora Packager Dashboard - Available for wide use to all packagers

Hi, We'd like to announce that the Fedora Packager Dashboard passed the testing period, was properly deployed inside Fedora Infrastructure, got fixes, improvements and feature additions and is now available for widespread use among all Fedora Packagers. For those of you who didn’t hear about the

Re: Attempting to allow for a source of truth for Fedora release cycle information: releasestream

On Wed, Feb 10, 2021 at 11:27 PM Debarshi Ray wrote: > Hey, > > I wanted to respond earlier, but it totally slipped my mind. > > We'd totally use releasestream in Toolbox for mapping the string > "rawhide" to a numeric version: > https://github.com/containers/toolbox/issues/646 > > Cheers, >

Re: [Qa-tools-sig] Orphaned packages looking for new maintainers

On Mon, Feb 8, 2021 at 4:57 PM Miro Hrončok wrote: > python-flask-openid orphan, pjp, sundaram 0 weeks > ago > Taken. We still need that for blockerbugs, sigh. It's dead upstream, replaced by oidc. I'll try to poke others depending on this (eg. copr) once we finish

Re: Beware: Querying a group's projects on src.fp.o and pagure.io currently broken

On Fri, Feb 5, 2021 at 6:01 PM Fabio Valentini wrote: > Hi everybody, > > Since the last pagure version was deployed, the API for querying a > group's packages (api/0/group/foo?projects=true) was broken - it is > now paginated, where before it was not: > > https://pagure.io/pagure/issue/5110 > >

Re: mesa 21.0.0-rc3 making rawhide really unstable?

On Tue, Feb 2, 2021 at 10:26 PM Marius Schwarz wrote: > Am 02.02.21 um 21:58 schrieb Matthew Miller: > > On Tue, Feb 02, 2021 at 12:36:36PM -0800, Kevin Fenzi wrote: > >> landed (from koji) and gnome-shell did crash while upgrading. I did of > >> course have the dnf running in a tmux session,

Planned Outage - Fedora Packager Dashboard - 2021-02-02 08:00 UTC

There will be an outage starting at 2021-02-02 08:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-02-02 08:00UTC' Reason for outage: Moving the project from its

Planned Outage - Fedora Packager Dashboard - 2021-02-02 08:00 UTC

There will be an outage starting at 2021-02-02 08:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2021-02-02 08:00UTC' Reason for outage: Moving the project from its

[EPEL-devel] Re: [EPEL7] Celery stack update & Python 3 enablement

On Mon, Oct 5, 2020 at 7:09 PM Kevin Fenzi wrote: > How big are the changes between 4.2.2 and 4.3? > So, I finally got back to this, sorry for the late reply. After reading through kombu 4.3 changelog [0], it seems the only truly breaking change is in SQLAlchemy transport ( I can be wrong, of

[EPEL-devel] [EPEL7] Celery stack update & Python 3 enablement

Hi, I've recently begun maintaining celery stack in Fedora and Fedora EPEL. I am in process of enabling python 3 builds of celery for EPEL 7, testing copr (in working state with at least redis backend) is available here for anyone interested:

Re: Orphaned packages looking for new maintainers

On Mon, Sep 21, 2020, 23:59 Dan Čermák wrote: > Miro Hrončok writes: > > > winetricksorphan, raphgro, tc010 > weeks ago > > Any particular reason why winetricks got orphaned? > Taken. > ___ devel mailing list --

Re: F34 Change: Reduce installation media size by improving the compression ratio of SquashFS filesystem (Self-Contained Change)

On Thu, Aug 27, 2020 at 5:16 PM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/OptimizeSquashFS > > == Summary == > Improve compression ratio of SquashFS filesystem on the installation media. > > == Owner == > * Name: [[User:bkhomuts|Bohdan Khomutskyi]] > * Email: bkhom...@redhat.com

Re: Fedora Packager Dashboard available for testing

On Mon, Aug 17, 2020 at 10:36 PM Dan Čermák wrote: > I know it has been a while since you sent around this email, but does > the packaging dashboard expose the shown information via an API? Hi, it does. API for packager dashboard is provided by oraculum, which is available here:

Re: F33 Change proposal: DXVK as default wined3d backend on VK capable hardware (Self-Contained Change)

On Thu, Jul 23, 2020 at 2:18 PM Dominik 'Rathann' Mierzejewski < domi...@greysector.net> wrote: > Is Vulkan supported on AMD Radeon HD 7900 series (TAHITI)? Some > sources I found say it is: > > https://vulkan.gpuinfo.org/listreports.php?devicename=AMD%20Radeon%20HD%207900%20Series > but

Re: Fedora Packager Dashboard available for testing

On Fri, Jun 26, 2020 at 12:10 AM Iñaki Ucar wrote: > Yesterday I fixed a FTBFS, but it's still showing in my dashboard. I > suppose that it takes some time to update, but how long should I > expect it to show there until I should suspect that there's some bug? > > Iñaki > Yeah, we are having

Re: Fedora Packager Dashboard available for testing

On Tue, Jun 23, 2020 at 9:15 PM Artem Tim wrote: > It's awesome, but for some reason my profile not showing here. Just gray > background. :( > https://packager.fedorainfracloud.org/atim > > There were some caching/data consistency issues on the server due to overload, I've manually fixed your

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

On Fri, Jun 5, 2020 at 9:57 AM Kevin Kofler wrote: > Ben Cotton wrote: > > == Summary == > > Fedora has historically forced packages to build with GCC unless the > > upstream project for the package only supported Clang/LLVM. This > > change proposal replaces that policy with one where compiler

Re: Fedora 33 System-Wide Change proposal: swap on zram

I am +1 for this change, I don't have any numbers but from day-to-day usage, both my systems seem far more responsive when swapping to zram instead of swap. On Fri, Jun 5, 2020 at 8:56 AM Kevin Kofler wrote: > I do not think it is safe to assume that zram is sufficient to completely > replace

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

On Fri, Jun 5, 2020 at 9:11 AM Igor Raits wrote: > Also we probably should mention that -fstack-clash-protection is not > available in clang, so in theory binaries can be less secure due to > that. > This seems to be worked on as per https://reviews.llvm.org/D68720?id=224102 (on x86, I am not

Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag

On Wed, Jun 3, 2020 at 12:46 PM Jonathan Wakely wrote: > On 03/06/20 12:35 +0200, Till Hofmann wrote: > > > > > >On 6/2/20 5:24 PM, Jonathan Wakely wrote: > >> ### C++ includes > >> > >> Several packages failed to build because they couldn't find C++ > >> Standard Library algorithms: > > > >>

Re: Urgently downgrade xorg-x11-drv-intel

On Fri, Apr 10, 2020 at 3:24 PM Alexei Podtelezhnikov wrote: > >> > >> Is koji still fc31? My problematic rebuilds are obviously fc32. > > > > > > All the scratch builds I spawned for this issue are for F32 of course. > > I am pondering a compiler bug. Your scratch builds are fine so it > seems.

Re: Clang/LLVM mismatch in F32?

is > higher than the release of rc2. > > Anyway, this should be fixed now. > > On Tue, Mar 17, 2020 at 8:27 AM Michael Cronenworth > wrote: > > > > On 3/17/20 7:00 AM, Frantisek Zatloukal wrote: > > > > > > I am trying to rebuild mozjs68 in F32[0]

Clang/LLVM mismatch in F32?

Hi, I am trying to rebuild mozjs68 in F32[0] (passed in rawhide just fine[1]), which buildrequires clang and llvm. However, clang and llvm versions mismatch in F32 buildroot: clang x86_64 10.0.0-0.2.*rc1*.fc32 llvmx86_64 10.0.0-0.1.*rc2*.fc32 which seems to

Re: mock inside docker

Hi, adding "--no-bootstrap-chroot" wouldn't help? On Thu, Mar 5, 2020 at 3:11 PM Christoph Junghans wrote: > Hi, > > if I am trying to run mock inside docker, I am getting the following error: > INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result > ERROR: Command failed: >

Re: Disabling Fedora 29 chroots in Copr

Got one about a day ago :) On Tue, Feb 18, 2020 at 12:17 PM Jakub Kadlcik wrote: > I would like to ask you, can anyone with non Red Hat email confirm, > that they get the notifications? The subject is > > > [Copr] upcoming deletion of outdated chroots in your projects > > > Thank you, > Jakub >

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

On Fri, Jan 3, 2020 at 10:14 PM John M. Harris Jr wrote: > Regardless, if this Change is accepted, it should probably be done on a > per- > spin basis. If the GNOME Spin wants this, that's one thing, but I don't > believe this would be a good idea on servers. > Yes, and if you read the change

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

On Wed, Dec 18, 2019 at 1:37 AM John M. Harris Jr wrote: > But it would mean that Fedora would potentially release with optical boot > broken. Yes, and it was said about a million times in all threads regarding this change proposal. There is no need to say it again and again. Yes, it can

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

On Tue, Dec 17, 2019 at 2:31 AM Adam Williamson wrote: > Still, we have F32 Beta coming up quite > soon, we could potentially delay this feature and see how that goes - > see if anyone besides RH Fedora QE staff shows up to run the tests... > We still can have optical media as non blocking,

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

On Sun, Dec 15, 2019 at 9:05 PM John M. Harris Jr wrote: > That was not brought up elsewhere in this thread. Who is considering this, > and > why? That would mean that a large portion of users would *not be able to > install Fedora*. > Just note that I mean blocking by "supported". I am not

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

On Fri, Dec 13, 2019 at 12:03 PM Miro Hrončok wrote: > Juts a random idea, not very thought-out: > > Could we keep optical media bugs reported by users as blocking, but not > require > it during validation testing? > > > aka: Fedora QE would no longer have to verify optical media works. > but:

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

On Sun, Dec 15, 2019 at 7:52 PM John M. Harris Jr wrote: > > Not working means broken. > Part of this proposal is removing optical media from supported installation methods. >From your point of view, Fedora is broken right now because, for example, it doesn't work from USB Media created by

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

On Sun, Dec 15, 2019 at 6:15 PM John M. Harris Jr wrote: > On Sunday, December 15, 2019 10:02:19 AM MST alcir...@gmail.com wrote: > > Hello all. > > Sorry but as far as I can understand, and as stated in the proposal as > > well by other people, the possibility to boot from optical media will >

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

On Thu, Dec 12, 2019 at 11:31 PM Adam Williamson wrote: > On Thu, 2019-12-12 at 15:37 -0500, Ben Cotton wrote: > > > > == Scope == > > * Proposal owners: Change [[Releases/32/ReleaseBlocking]] to indicate > > we no longer block on optical media, change Validation Testing > > Matrices > > I don't

Re: Fedora 32 System-Wide Change proposal: Drop Optical Media Release Criterion

On Fri, Dec 13, 2019 at 9:28 AM Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote: > On 12.12.2019 21:37, Ben Cotton wrote: > > Proposal to make all Fedora optical media non-blocking. This means > > we'd stop blocking on bugs found during the installation of Fedora > > from optical

Re: gstreamer-plugins-base revival

On Fri, Nov 22, 2019 at 12:47 PM Leigh Scott wrote: > > Please don't revive ancient, unmaintained, security-critical libraries > > for use with proprietary software not distributed by Fedora > Old gstreamer is used by a couple of ancient apps in fedora (banshee) > Banshee in Fedora is using

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

On Sat, Nov 9, 2019 at 8:31 AM Kevin Kofler wrote: > Sorry, but I'm with Vít there. If Python is running into toolchain > limitations, the goal should be to work on improving the toolchain, not to > add a hack with side effects (bloat, compatibility issues) to the Python > package, a hack with

Re: Will orphan packages with NEW F31FTBFS bugs tomorrow

On Fri, Nov 8, 2019 at 1:17 PM Miro Hrončok wrote: > python-pyopencl Fixed, FTBFS bug closed: https://bugzilla.redhat.com/show_bug.cgi?id=1736526 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Orphaned packages looking for new maintainers (incl. wine, dosbox, nextcloud, owncloud)

On Wed, Nov 6, 2019 at 9:11 PM Gwyn Ciesla via devel < devel@lists.fedoraproject.org> wrote: > Ok. :) And I'll take wine if absolutely no one else will, but as a last > resort. :) > I can take wine if you want that only as a last resort :) But, I'd be happy if you would co-maintain that, more

Re: Is noautobuild still a thing?

Yeah, looks like mass rebuild just skips these packages: https://pagure.io/releng/blob/master/f/scripts/mass-rebuild.py#_125 I am wondering if it wouldn't make sense to do a scratch build in that case and proceed with normal FTBS policy [0] if it fails. [0]

  1   2   >