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:
> >
> >> fr
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 su
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 di
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
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 pro
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 som
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 vulkaninf
Best regards / S pozdravem,
František Zatloukal
Project Coordinator
Red Hat
- Original Message -
From: "Owen Taylor"
To: "Development discussions related to Fedora"
Cc: developer-por...@lists.fedoraproject.org, websi...@lists.fedoraproject.org,
"Frantisek Zat
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.
Hi,
I think retrace service is running on RHEL 7.7 server and since we have
zstd rpms in Fedora 31 [0], it won't work. I don't know what's the ETA for
fix, I can ask on Tuesday, if there is any update on this issue.
Until then, you'll probably have to generate stack traces locally :/
[0] https:/
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]
https://docs.fedoraproject.org/en-US/fe
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 pe
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 devel-le...@lists
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 wh
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
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 m
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
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
> >
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 UNetb
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: If
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 talk
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, that
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 resu
On Mon, Jul 15, 2019 at 11:58 AM Jiri Vanek wrote:
> On 7/15/19 11:34 AM, Vitaly Zaitsev via devel wrote:
> > Hello, Dridi Boukelmoune.
> >
> > Mon, 15 Jul 2019 08:26:59 + you wrote:
> >
> >> Emulate as in not run natively even though the hardware might be able
> to?
> >
> > Sorry for misinfo
Hi,
this is probably question for mutter/gnome-shell maintainers. But as I see
it, there is a reason why are those patches not backported into stable
branches in upstream. There can be regressions, the thing that you have
zero issues doesn't mean anybody else won't have them. Backporting those
pat
Hi,
I've proposed some packaging changes [0] to Fedora wine package. TLDR: It
splits d3d libraries into subpackages and lays groundwork for future dxvk
packaging [1]. Details are in the PR.
*What is DXVK?*
Vulkan-based D3D11 and D3D10 implementation for Linux / Wine. In short, you
can replace wi
Personally, I am not at all against raising the bar for baseline x86_64. Of
course, it'd be ideal to have some sort of derived x86_64_avx arch, but if
we find out it'd require too much of an investment into infra/releng, I'd
be +1 for just changing the base x86_64. Sure, it'd make sense to actually
>
>
> And that is sufficient. As long as it compiles, you can package it.
> Whether
> upstream "supports" it or not is irrelevant.
It depends on package maintainer. If upstream dropped 32-bit support, I'd
stop building it for that arch in Fedora.
Why would package maintainer have to bear the bur
I don't think it's that late for FE for F31 Beta, but this is something we
can discuss on our meeting tomorrow.
CCing Adam.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora
Also, I have feeling that Lutris is far superior alternative, at least for
games :)
On Tue, Sep 10, 2019 at 4:01 PM Michael Cronenworth wrote:
> On 9/10/19 8:35 AM, Miroslav Suchý wrote:
> > This will lock me in the Steam only:)
>
> We ship wine-staging, which should handle any Windows game.
> _
Hi,
recently, I've seen few users running Fedora with nomodeset. They didn't
know about that and were just complaining about poor resolution and/or
performance (and those systems worked just fine without nomodeset). Also,
sometimes, users choose basic video driver because something is broken, but
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 wi
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
>
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:
>
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
1 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 F3
Why is this Self-Contained Change and not a System Wide Change?
It seems, at least to me, that it should be System Wide Change, according
to https://fedoraproject.org/wiki/Changes/Policy#Complex_system_wide_changes
.
On Fri, Jan 25, 2019 at 3:45 PM Ben Cotton wrote:
> https://fedoraproject.org/
On Fri, May 31, 2019 at 1:22 PM Jan Pazdziora wrote:
> On Fri, May 31, 2019 at 12:53:35PM +0200, Jan Tulak wrote:
> > Hi guys
> >
> > I'm trying to enable gating tests for package system-storage-manager.
> > The tarball contains upstream tests and I would like to use these
> > (with the ability t
On Wed, Jun 26, 2019 at 12:17 AM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:
> On Tuesday, 25 June 2019 at 14:36, Bruno Wolff III wrote:
> > On Mon, Jun 24, 2019 at 23:17:30 -0500,
> > Justin Forbes wrote:
> > >
> > > It is not a violent cheat. It was proposed this way 2 year
We have encountered a bug[0] which seemingly “broke” offline updates after
systems were upgraded from an older Fedora to Fedora 29 and had some
multilib packages installed. After the discussion at last week's Release
Retrospective meeting, I am proposing some changes to our blocking
criterions in o
On Mon, Nov 19, 2018 at 6:43 AM Kevin Kofler wrote:
> If you follow exactly this procedure, the set of "the multilib packages
> installed before" will be empty and you will not reproduce the issue at
> hand. Multilib cruft has not been installed by default for years now! (And
> that is a good thi
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 Fedo
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 wasn't
>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 wh
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 degr
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 i
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: https://koji.fedoraproject.
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
>
Hello Kefu,
At this point, I'd probably say go ahead and build a new fmt 11 and fmt 10
compat in rawhide proper. There is a mass rebuild starting tomorrow which
will take care of the rebuilds, and since you've introduced the compat
package, there is no much harm this can cause.
On Tue, Jul 16, 20
On Tue, Jul 16, 2024 at 11:19 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
> I've rebuilt some important dependent packages (spdlog) in this side
> tag, so technically we can merge this side tag today before the mass
> rebuild starts.
>
Yeah, you're right, missing that woul
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
clang
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
> > n
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 message)
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 a
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 runni
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 brlap
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 entirely
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 bas
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 now.
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 >
> > wrote:
>
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.fe
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 sen
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 case,
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 ha
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:
>
> https://qa.fedora
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. If
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 pa
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 that
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
> > ( htt
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 1
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:
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 replacement
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,
Fran
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
2024 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, li
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
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 enabl
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 (
https://bugzilla.redhat.com/show_bug.cg
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 )
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 t
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,
Fran
vponcova left Red Hat, and I don't think she'll be continuing to maintain
the packages,
Adding mkolman to CC.
On Fri, May 3, 2024 at 10:57 AM Pierre-Yves Chibon
wrote:
> Good Morning Everyone,
>
> We have been emailing daily the following users to notify that the email
> they
> have set in FAS
On Mon, May 13, 2024 at 3:42 PM Vít Ondruch wrote:
>
> My point is that we can spent time maintaining llvm00 - llvm99 packages
> or we can spent time adjusting upstream projects to be compatible with
> the latest llvm.
>
There are many projects that require a fair amount of work to be ported to
Hey,
just FYI, this was/is in progress by me, you could've checked upstream PRs:
https://github.com/oneapi-src/level-zero/pull/149 and
https://github.com/oneapi-src/level-zero/pull/150 . It was pending on
https://src.fedoraproject.org/rpms/spdlog/pull-request/2 that was merged
pretty recently.
On
On Sun, Jun 30, 2024 at 6:07 PM Ben Beasley wrote:
> The latest upstream release of python-llvmlite now has “experimental”
> support for LLVM 15, and the package is now built with LLVM 15 in Rawhide.
> Upstream plans to support LLVM 17 or later “eventually,” but the timeline
> is indefinite (http
I've pushed a new build of level-zero (of an upstream release which has my
system spdlog support patch upstreamed):
https://src.fedoraproject.org/rpms/oneapi-level-zero/c/328c4a33aa05d4ccf5b697cf2e67188750663913?branch=rawhide
. f40 build will follow once the new opencl-headers reach the stable
upd
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 changes
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 s
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-
et=-4000
File not found:
/builddir/build/BUILDROOT/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 P
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 a
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: https://packag
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
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 -- de
Reported: https://bugzilla.redhat.com/show_bug.cgi?id=1490351
I am thinking about proposing this as Blocker Bug/PrioritizedBug, it's
pretty significant regression compared to current state on Fedora 26.
On Mon, Sep 11, 2017 at 1:06 PM, Kalev Lember wrote:
> On 09/11/2017 10:49 AM, Vít Ondruch
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 ar
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
hop
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 b
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
___
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 tried
1 - 100 of 122 matches
Mail list logo
