Vitaly Zaitsev via devel writes:
> On 22/05/2024 01:45, Tom Stellard wrote:
>> I looked in the iwyu source, and it's not using ${LLVM_LIBRARY_DIR}
>> correctly.
>> That variable points to where the libraries are installed, but iwyu is
>> using it to look
>> up the resource directory. iwyu
Miro Hrončok writes:
> It first showed up in
> https://src.fedoraproject.org/rpms/python3.13/pull-request/58
>
> The Ci has all the logs, e.g.
>
> https://kojipkgs.fedoraproject.org//work/tasks/8452/117468452/build.log
Thanks for these links.
It looks like this is happening because the tests
Siddhesh Poyarekar writes:
> _FORTIFY_SOURCE (any level) should work perfectly with -O (any level).
Is this new? Or do you mean any level where optimization is enabled?
i.e. -On, where n >= 1
Anyway, a warning should be printed when using -O0 unless -Wno-cpp is
also used.
annocheck's source
Neal Gompa writes:
> You also have to do new package
> reviews for each new version instead of using the compatibility
> package exception to branch older releases into compatibility
> packages.
I don't think this will be needed because it is one of the exceptions [1]:
The package is being
Nico Kadel-Garcia writes:
> On Sat, Apr 27, 2024 at 12:35 AM Tom Stellard wrote:
>> * Invert the order of compat/main packages. Instead of having the compat
>> package be
>> the old version, and the main package be the new version, we would have the
>> compat package
>> be newer and the main
Aoife Moloney writes:
> == Scope ==
> * Proposal owners: add a valkey-compat package which will port Redis
> configurations to Valkey. Valkey 7.2.5 is 100% compatible with Redis.
> Add "Obsolete: redis" to valkey-compat package.
I suggest to also mention in the presence of `Conflicts: redis`
Sirius via devel writes:
> echo % of original
> echo Time to decompress the file, output to /dev/null
> time gzip -d -c ${INPUTFILE}.gz > /dev/null
Keep in mind that gzip has its own zlib implementation, while
createrepo_c uses the system-provided zlib.
That means, when creating a
Miroslav Suchý writes:
> I just upgraded my workstation to F40 and it surprised how many packages were
> reported by `remove-retired-packages`.
> There was lots of orphaned packages - there is nothing to do about them. But
> there was lot of packages that were removed
> intentionally. See the
"Martin Gansser" writes:
> Hi,
>
> when compiling openclonk [1] on rawhide it fails with this error message [2]:
> /usr/bin/cmake -E cmake_link_script CMakeFiles/c4group.dir/link.txt
> --verbose=1
> /usr/bin/g++ -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe
The zlib-ng-compat and minizip-ng-compat packages have been in Rawhide for
more than a month.
Considering things have been working well, we believe it's time to retire the
zlib and minizip-compat packages.
This step should not cause any changes, because zlib-ng-compat and
minizip-ng-compat
Tulio Magno Quites Machado Filho writes:
> Following the recent approval from Fesco, I'm planning to distribute
> zlib-ng-compat packages for Rawhide later this week.
> I hope this will give us enough time to work on the issues before
> Fedora 40 is released. 爛
>
>
Yaakov Selkowitz writes:
> Except that it's not 100% compatible, since all those packages aren't
> building/working with zlib-ng-compat. At a minimum, you should be able
> to show that everything zlib-dependent successfully rebuilds with this,
I'm afraid I was not clear enough.
Packages built
Yaakov Selkowitz writes:
> Also, since this is essentially an SONAME change wrt zlib, the initial
> build and mini-mass-rebuild of all dependents should occur in a side-
> tag. You're announcement doesn't mention this occurring.
There are no SONAME changes.
With zlib we have:
$ rpm -qf
Miro Hrončok writes:
> Do you happen to have a build.log available for this?
I re-run the tests for all architectures here:
https://copr.fedorainfracloud.org/coprs/tuliom/zlib-ng-compat-mpb/build/6726758/
Keep in mind that zlib-ng defines the following:
#define ZLIB_VERSION "1.3.0.zlib-ng"
Re-sending to binutils, openexr and python3.12 maintainers.
Sorry, I messed up your email aliases in my first message.
--
Tulio Magno
Tulio Magno Quites Machado Filho writes:
> Following the recent approval from Fesco, I'm planning to distribute
> zlib-ng-compat packages for Rawhide
Following the recent approval from Fesco, I'm planning to distribute
zlib-ng-compat packages for Rawhide later this week.
I hope this will give us enough time to work on the issues before
Fedora 40 is released. 爛
So, keep in mind this will *obsolete zlib in Rawhide*.
This update is also known
"Richard W.M. Jones" writes:
> However if we succeed in making zlib-ng be the default with the
> compatible zlib API then I'll remove that change.
Ideally, it's prefered to use the zlib-ng API
Any reasons for switching back?
--
Tulio Magno
___
devel
Julian Sikorski writes:
> Does a hammer smaller than -g1 also exist for issues like:
>
> relocation truncated to fit: R_X86_64_32 against `.debug_info'
> https://kojipkgs.fedoraproject.org//work/tasks/1615/107091615/build.log
This is saying that mame is too large to fit in the default code
Sébastien Le Roux writes:
> Dear all,
> in the past weeks the updates of GCC for both Fedora and Debian have
> introduce few identical Fortran modifications:
>
> fortran/108961
> fortran/109684
> fortran/110825
>
> As a result my I cannot build the RPM package (nor the Debian package)
> for my
"Kai A. Hiller" writes:
> Hello,
>
> I started a build with `fedpkg build`, but after 43h and counting I
> don‘t think it will finish anymore. Is there a way to terminate the
> build? The build is
> https://koji.fedoraproject.org/koji/taskinfo?taskID=106154761
Look for this command:
dnf
Matthew Miller writes:
> Everything is a balance.
>
> Even if you don't want to follow Fedora Discussion in general, to follow
> changes, you can go subscribe to just those by email.
>
> 1. Sign in you with your Fedora account
>
> 2. Complete creating a Discussion account if you haven't already
I went ahead and started to modify Jacek's initial proposal [1] in order
to integrate the feedback from this thread as well as some changes I had
in mind.
I have created a RFC pull request [2]. Hopefully this will help answer
some of the questions we've seen here. Feedback is appreciated.
I have
s
> for @Tulio Magno Quites Machado Filho <mailto:tmach...@redhat.com> :
> 1) Just to clarify, do you want to have two separate packages (zlib-ng and
> e.g. zlib-ng-compat) in Fedora? One with the `-DZLIB_COMPAT=ON` option
> enabled and one without it?
Yes. While I do not have
"Richard W.M. Jones" writes:
> The background to this is I've spent far too long trying to optimize
> the conversion of qcow2 files to raw files. Most existing qcow2 files
> that you can find online are zlib compressed, including the qcow2
> images provided by Fedora. Each cluster in the file
I noticed that a few change proposals that have been approved still did
not get a bug tracker, e.g.: https://fedoraproject.org/wiki/Changes/LLVM-17
As things have changed this release, I'm wondering if the process
changed.
Is the bug creation still in plan?
--
Tulio Magno
Florian Weimer writes:
> Today, I pushed a redhat-rpm-config update to rawhide,
> redhat-rpm-config-260-1.fc39. The only expected change is that
> -Wno-complain-wrong-lang now shows up in %optflags (but not
> %build_cflags etc.). It should prevent Fortran compilers from warning
> on
Kevin Kofler via devel writes:
> Carlos O'Donell wrote:
>> And assembling those sysroots is not straight forward.
>
> The easiest way is to unpack a live image. If you are targeting an Arch-
> based or similar distro, you will probably get away with just unpacking the
> image, because it
> On 06/01/2021 Daniel Pocock wrote:
>
> Most packages compiled on one type of kernel will run on the other type
> but there could be a very small number that have to be recompiled if the
> Fedora kernel changes down to 4k.
I'm afraid changing the page size would be more complicated than that.
28 matches
Mail list logo
