The `CMAKE_INSTALL_LIBDIR` should not be an absolute path, and afaict
`%{_libdir}` expands to absolute path. Maybe you can patch the
CMakeLitsts.txt to accept a variable of QT_VERSION and alter the install
directive there.
On 2024/07/08 10:18, Martin Gansser wrote:
Hi,
with the option
-DCM
On 2024/07/09 17:09, Sandro via devel wrote:
On 09-07-2024 17:01, David Bold wrote:
Is it possible to have a PR without any code changes?
Is there an alternative, recommended way to ask for rebuilds?
Specifically in the case of %autorelease, you can bump the release
with an empty commit:
g
On 2024/07/12 11:49, Zbigniew Jędrzejewski-Szmek wrote:
Should we just put a huge redirect on whatcanidoforfedora to
https://fedoraproject.org/wiki/Welcome?
I edited https://fedoraproject.org/wiki/Welcome to have the nice
"Welcome to Fedora!" banner at the top. The page was a bit cool without
a
Hi Zbyszek,
On 2024/07/14 20:04, Zbigniew Jędrzejewski-Szmek wrote:
I'm looking for a solution which doesn't just skip the installability
tests altogether.
On PRs with zuul or FedoraCI automation, the same instability tests that
are done for Bodhi are performed. But what would help is to make
On 2024/07/15 13:52, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jul 15, 2024 at 01:26:09PM +0200, Petr Pisar wrote:
V Mon, Jul 15, 2024 at 08:45:53AM +, Zbigniew Jędrzejewski-Szmek napsal(a):
Maybe I conflate installability tests with rpmdeplint tests. We need both:
A test which checks that
Hi Marian,
Thanks for the comments. We all had our turns being horrified by this
project. The more you look at it the more you want to use bleach as
eye-drops. Germano is trying to write an issue to at least try to steer
the upstream project in a more sensible directions.
On the CMake side,
On the dist-git I don't think there is any. For bodhi though you can
make `gating.yaml` file. Here [1] is one which includes `rpminspect`
```yaml
--- !Policy
product_versions:
- fedora-*
decision_contexts:
- bodhi_update_push_stable
subject_type: koji_build
rules:
- !PassingTestCaseRule {t
On 2024/08/01 17:27, Owen Taylor wrote:
On Thu, Aug 1, 2024 at 9:24 AM Neal Gompa wrote:
Well, if you have a general package that's shipped in every buildroot
for flatpak builds, you can ship your own wrapper, and I can make it
check if RPM_BUILD_ROOT is defined *and* this file exi
On my system I get an exiv2/krita issue and a re2 issue:
```
Error:
Problem 1: problem with installed package krita-5.2.2-7.fc40.x86_64
- package krita-5.2.2-11.fc41.x86_64 from fedora requires
libexiv2.so.27()(64bit), but none of the providers can be installed
- krita-5.2.2-7.fc40.x86_64 f
It might also be worth mentioning that both gitea and forgejo support
Github Actions [1][2]. I did not personally test them, but it might be
good for the familiarity and reuse of the maintained Github Actions
library. One missing thing are Github applications, but I don't think we
are using som
Agree it should be in Fedora CI. Maybe it can be added to the Zuul CI,
or the default scratch build.
But to run Fedora CI, the source would need to be in the look-aside
cache. I think it would be ok that if the packit run is
pull_from_upstream that a licensecheck is run (after the spectool -g
Hi Stephen,
Could you also share the links for where the strategies for large builds
is, I am also curious about this? Is it within koji or another framework?
On 2023/10/04 14:41, Stephen Smoogen wrote:
On Wed, 4 Oct 2023 at 05:44, Martin Stransky wrote:
Hello guys,
Is there's a
sets take
this into account? I believe %ctest ones do that, but I've found an MPI
related situation where I need to override this.
Also are the options equivalent in copr as well?
On 2023/10/04 15:32, Stephen Smoogen wrote:
On Wed, 4 Oct 2023 at 09:24, Cristian Le via devel
wrote
Just want to share about fedrq, since I was also bitten by such issues.
It gets all packages that BuildRequires/Requires a specific package.
Should be able to make a thread of the corresponding
-maintainers mailing list and share a copr project about this
upgrade.
On 2023/10/04 15:43, Remi Co
Can join the #fedora-ci:fedoraproject.org matrix group.
On 2024/02/06 14:16, Sandro wrote:
On 06-02-2024 10:32, Karolina Surma wrote:
Please note, if you want to add hundreds of packages at once,
coordinate with the Zuul folks -- they know best how much it can handle.
Do you happen to have co
Are you using IRC? The IRC bridge is dead I think around that time. You
might have to use a proper matrix client in this case.
We are active even yesterday.
On 2024/02/06 14:38, Sandro wrote:
On 06-02-2024 14:27, Cristian Le via devel wrote:
Can join the #fedora-ci:fedoraproject.org matrix
2024 14:43, Cristian Le via devel wrote:
Are you using IRC? The IRC bridge is dead I think around that time.
You might have to use a proper matrix client in this case.
I joined the Matrix room (https://matrix.to/#/#fedora-ci:fedora.im).
We are active even yesterday.
Then I somehow do not get
Hi,
Here's my contribution to this: error upgrading `flang-devel`
https://bugzilla.redhat.com/show_bug.cgi?id=2267221
On 2024/02/21 8:11, Miroslav Suchý wrote:
Do you want to make Fedora 40 better? Please spend 1 minute of your
time and try to run:
# Run this only if you use default Fedora
Zbyszek
While I am in favor of autospec, I agree with the comment that it
doesn't work well outside of koji.
- builds in copr work.
The builds themselves work, but in my experience they do not increase
the `release`, nor do they handle `autochangelog`. Are there ways around
it if we want
On 2024/05/27 10:09, Vitaly Zaitsev via devel wrote:
On 27/05/2024 02:46, Kan-Ru Chen wrote:
It is documented that FIND_PACKAGE_ARGS argument in
FetchContent_Declare should instruct it to find system packages first.
This only works as expected in very rare cases. The library name in
FetchCon
Hi,
RPM 4.20 broke CPack, which is commonly used by many developers to
produce RPM packages:
https://gitlab.kitware.com/cmake/cmake/-/issues/26021
The bugzilla bug linked at the top has been resolved. Still the CPack
RPM is still fairly outdated and weird in some places, e.g. defining
BuildR
On 2024/09/17 12:35, Fabio Valentini wrote:
On Tue, Sep 17, 2024 at 11:23 AM Ankur Sinha wrote:
Hi folks,
I have a few rust packages that need to be reviewed for Taskwarrior v3.
Would anyone like to swap reviews please?
-https://bugzilla.redhat.com/show_bug.cgi?id=2307663:
rust-google-clou
You can find contact information in the accounts page [1], although
Neal's is a huge one, not sure which one is the most relevant to use
other than the matrix channel.
I have left a comment on the PR with more details on what you can do to
contact and make the PR more reviewable, but it genera
On 5 February 2025 06:17:01 CET, Orion Poplawski wrote:
>cc1plus: all warnings being treated as errors
>gmake[2]: *** [libmambapy/CMakeFiles/bindings.dir/build.make:96:
>libmambapy/CMakeFiles/bindings.dir/src/libmambapy/bindings/legacy.cpp.o] Error
>1
>
>I'm guessing 'SR.32262' is some kind of
On 2025/01/19 18:32, Michael J Gruber wrote:
Mattia Verga venit, vidit, dixit 2025-01-19 18:28:04:
For example:
https://kojipkgs.fedoraproject.org//work/tasks/7044/127997044/build.log
I don't know much of C, from what I've read online those functions are
declared without arguments and then us
On 2025/01/27 21:15, Sérgio Basto via devel wrote:
On Mon, 2025-01-27 at 20:52 +0100, Cristian Le via devel wrote:
According to the CPP standard, and the deprecation was
added in CPP20 [1] so would be best not to patch that part
unconditionally in the gtest source. Maybe you could patch in a
According to the CPP standard, and the deprecation was added in CPP20
[1] so would be best not to patch that part unconditionally in the gtest
source. Maybe you could patch in a pragma to disable the warning instead?
Another option could be to drop the CPP standard check altogether and rely on
On 28 January 2025 01:11:22 CET, "Sérgio Basto via devel"
wrote:
>On Mon, 2025-01-27 at 19:31 +, Sérgio Basto via devel wrote:
>>
>> On rawhide I got the warning, on Fedora 41 don't but __cplusplus of
>> GCC
>> compiler is the same (201703)
>
>
> __cplusplus value GCC on rawhide should be
If anyone knows how to contact sham1, please let me know. I've sent an email
to his/her personal email but haven't got a response. The pull request has been
unreviewed for more than 3
weeks:https://src.fedoraproject.org/rpms/maildir-utils/pull-request/9
I don't know sham1, but I presume you
On 1/15/25 2:33 PM, Fabio Valentini wrote:
No, AFAIK the @fedoraproject.org email alias should work for
all users who are in CLA+1 or something (so it should work for all
members of the "packager" group, for example, since signing the CLA is
prerequisite for joining the "packager" group).
Inde
On 2025/02/20 14:54, Ben Beasley wrote:
Note that as long as we’re on Pagure, it’s impossible to make a PR for
an empty commit.
Right, that is indeed a nuisance. There is a dirty hack to it [1]:
1. Try to create the PR as normal and be greeted by a disabled "Create
Pull Request"
2. Enter de
On 2025/02/20 13:17, Miro Hrončok wrote:
What if we allowed all packagers to push empty commit to any package?
That should eliminate *some* need for provenpackager access. We would
also communicate in our policies that such bumps do not require prior
agreement with the maintainers to avoid con
On 2025/03/11 17:17, Fabio Valentini wrote:
On Tue, Mar 11, 2025 at 5:12 PM Michael J Gruber wrote:
Given the many packit related ones - does packit have a concept of
"follow Fedora release branching" (like COPR), or do packit users have
to update their config after a branch event?
Many projec
On 2025/03/12 13:22, Michael J Gruber wrote:
Interesting.
This is also a perfect example of how *not* to write git commit nor
changelog messages: everybody who can read those few lines of diff will
know what got removed and that it wasn't "standard" (or else it would
not have been defined manua
On 2025/03/18 11:35, Zbigniew Jędrzejewski-Szmek wrote:
At the technical level, you may be completely right. But at the level
of the organization of the work in the distro, this change is very
disruptive.
Yes, I am not arguing that the pushing of my PR without a change
proposal was a bad idea
35 matches
Mail list logo