Re: Inadvertent mass-rebuild triggered soname bump in libnfs

[Stephen Smoogen]

On Sun, 26 Jan 2025 at 13:26, Björn Persson  wrote:

> Fabio Valentini wrote:
> > On Sun, Jan 26, 2025 at 4:40 PM Stephen Gallagher 
> wrote:
> > > It's possible that I'm in the minority here, but I honestly don't
> think anything should be pushed to dist-git unless it's intended to be
> built more or less immediately. Yes, even changes without an immediate
> functional impact like the SPDX changes.
> > >
> > > That said, I agree with Kevin that we should have the compose reports
> list anything in the compose whose state is "The commit at the HEAD of the
> `rawhide` branch does not match the commit used for the latest build in
> Rawhide" and treat that as a bug (ideally, we'd open one automatically)
> that must be resolved prior to the next mass-rebuild (either by getting a
> build done or tagging the bug in some way that indicates that it's okay for
> the mass-rebuild to build it). Anything still on the list when the
> mass-rebuild is ready to start should be skipped and the bug should be
> marked as a blocker for Beta (to make sure it gets looked at). Detecting
> this should be fairly easy, albeit adding a bit to the Koji API load.
> >
> > I agree. I don't think anything should be pushed into dist-git that
> > isn't built for rawhide for like ... maybe > 3 weeks (or built in
> > side-tags and not submitted to bodhi in a similar time-frame). Mass
> > changes like the SPDX migration shouldn't be a special case here -
> > after all, the spec file changes will never end up in repositories if
> > they're pushed but never built.
>
> If I correct a typo in a comment, I should bump the release and cause
> churn on build servers and mirrors, even though nothing at all changes
> in the binary package?
>
>
I am going to say yes because I have seen enough 'I only was fixing a
comment' bug fixes which either broke the build or found the build was
broken for some reason. Those problems can be anything from 'compiler
problems' with the fixed comment to 'ohh I pushed a bunch of code I didn't
mean to..'

Packages get bumped and rebuilt for many reasons outside of the mass
rebuild. One of the reasons for the 'always ready rawhide' in years past
was because release engineering or other people were having to scramble
during a security update or some other problem fixing packages because they
did not build.


Björn Persson
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inadvertent mass-rebuild triggered soname bump in libnfs

[Vít Ondruch]

Dne 26. 01. 25 v 16:40 Stephen Gallagher napsal(a):



On Sat, Jan 25, 2025 at 12:24 PM Miro Hrončok  wrote:

On 24. 01. 25 22:13, Adam Williamson wrote:
> Note that side tags aren't the only issue. Sometimes a maintainer
> commits a bump to git but doesn't build it in a side tag or rawhide,
> for whatever reason. Sometimes a package is*built*, but gated from
> Rawhide by automated tests, but then the mass rebuild effectively
> overrides the gating (we found several cases like this). Just
checking
> side tags isn't gonna catch everything. I really think the
appropriate
> check is 'was the build most recently tagged into fXX built from the
> current git commit? if not, don't rebuild this package, yell for
manual
> intervention'.

Generally, this sounds like a good idea.

However, note that is is not uncommon for (proven)packagers to
commit stuff
that will only eventually get built. We might discover that the
number of
packages that we yell at for no good reason is too high.

As an example of a big chnage, I think the SPDX commits were
pushed but not built.


It's possible that I'm in the minority here, but I honestly don't 
think anything should be pushed to dist-git unless it's intended to be 
built more or less immediately. Yes, even changes without an immediate 
functional impact like the SPDX changes.



I would agree with your statement if I was considering this just from 
mass-rebuild perspective. But considering usage of those packages, I 
believe that we should always consider the amount of updates.


If I ignore that am Rawhide user consuming such changes, updated package 
in Rawhide also means that maybe others mock caches will become obsolete.



Vít





That said, I agree with Kevin that we should have the compose reports 
list anything in the compose whose state is "The commit at the HEAD of 
the `rawhide` branch does not match the commit used for the latest 
build in Rawhide" and treat that as a bug (ideally, we'd open one 
automatically) that must be resolved prior to the next mass-rebuild 
(either by getting a build done or tagging the bug in some way that 
indicates that it's okay for the mass-rebuild to build it). Anything 
still on the list when the mass-rebuild is ready to start should be 
skipped and the bug should be marked as a blocker for Beta (to make 
sure it gets looked at). Detecting this should be fairly easy, albeit 
adding a bit to the Koji API load.





OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: glusterfs-coreutils: Retired in rawhide

[Anoop C S via devel]

Retirement in effect with
https://src.fedoraproject.org/rpms/glusterfs-coreutils/c/9b9b5240c2305cfa6dbeb9be7dbccc4b389939a7?branch=rawhide


Anoop C S.

On Thu, 2025-01-23 at 10:27 +0530, Anoop C S via devel wrote:
> On Fri, 2025-01-10 at 16:44 +0530, Anoop C S wrote:
> > Hi,
> > 
> > Following the announcement[1] on intention to retire main GlusterFS
> > package from Fedora 42 I thought it wouldn't make sense to have
> > glusterfs-coreutils package as it is heavily dependent on
> > glusterfs.
> > There is no active development effort in upstream[2] for glusterfs-
> > coreutils.
> > 
> > Therefore I intend to retire glusterfs-coreutils in Fedora 42
> > unless
> > someone steps up to take over as next package owner.
> > 
> > [1]
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/D4QN2OFKQWN66HVKUG4CG4XPRW5ON62Z/
> > [2] https://github.com/gluster/glusterfs-coreutils
> > 
> > 
> > Anoop C S.
> 

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inadvertent mass-rebuild triggered soname bump in libnfs

[Vít Ondruch]

Dne 27. 01. 25 v 15:58 Stephen Gallagher napsal(a):



On Mon, Jan 27, 2025 at 9:40 AM Vít Ondruch  wrote:


Dne 26. 01. 25 v 16:40 Stephen Gallagher napsal(a):



On Sat, Jan 25, 2025 at 12:24 PM Miro Hrončok
 wrote:

On 24. 01. 25 22:13, Adam Williamson wrote:
> Note that side tags aren't the only issue. Sometimes a
maintainer
> commits a bump to git but doesn't build it in a side tag or
rawhide,
> for whatever reason. Sometimes a package is*built*, but
gated from
> Rawhide by automated tests, but then the mass rebuild
effectively
> overrides the gating (we found several cases like this).
Just checking
> side tags isn't gonna catch everything. I really think the
appropriate
> check is 'was the build most recently tagged into fXX built
from the
> current git commit? if not, don't rebuild this package,
yell for manual
> intervention'.

Generally, this sounds like a good idea.

However, note that is is not uncommon for (proven)packagers
to commit stuff
that will only eventually get built. We might discover that
the number of
packages that we yell at for no good reason is too high.

As an example of a big chnage, I think the SPDX commits were
pushed but not built.


It's possible that I'm in the minority here, but I honestly don't
think anything should be pushed to dist-git unless it's intended
to be built more or less immediately. Yes, even changes without
an immediate functional impact like the SPDX changes.



I would agree with your statement if I was considering this just
from mass-rebuild perspective. But considering usage of those
packages, I believe that we should always consider the amount of
updates.

If I ignore that am Rawhide user consuming such changes, updated
package in Rawhide also means that maybe others mock caches will
become obsolete.


So, in the case of Branched/Stable Fedora, we can always opt not to 
submit a Bodhi update to avoid bugging people.



I might have lost a track already, but wasn't one of the concerns build 
of package in side-tag, which is in my understanding is similar to not 
submitting update in stable versions?



Vít



With Rawhide's automated updates, that does indeed lead to more churn, 
but I'd argue that this is probably not a major issue. The majority of 
Rawhide usage is likely to be in CI systems rather than end-user 
systems (Kevin, myself and other insane people who run Rawhide on our 
primary machines notwithstanding).


So I don't think the impact would be terrible.


That said, I agree with Kevin that we should have the compose
reports list anything in the compose whose state is "The commit
at the HEAD of the `rawhide` branch does not match the commit
used for the latest build in Rawhide" and treat that as a bug
(ideally, we'd open one automatically) that must be resolved
prior to the next mass-rebuild (either by getting a build done or
tagging the bug in some way that indicates that it's okay for the
mass-rebuild to build it). Anything still on the list when the
mass-rebuild is ready to start should be skipped and the bug
should be marked as a blocker for Beta (to make sure it gets
looked at). Detecting this should be fairly easy, albeit adding a
bit to the Koji API load.


-- 
___

devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue




OpenPGP_signature.asc
Description: OpenPGP digital signature
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [rfc] mass package change to introduce sysusers.d configs

[Lennart Poettering]

On Sa, 25.01.25 09:27, Peter Robinson (pbrobin...@gmail.com) wrote:

> > trousers
>
> Trousers needs to be the same as the the tpm2-tss as they both deal with
> the TPM (the former v1 variants the later TPMv2).

What's the background here? Is this about device access? i.e. do both
packages install a udev rule to pass ownership of the relevant tpm
devices to the special "tss" group?

Given the ubiquity of tpm devices I am kinda tempted to move the "tss"
group and rules into systemd/udev proper. Then all relevant other packages
could drop their rules and there would not be any conflict of
ownership anymore.

Lennart

--
Lennart Poettering, Berlin
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux f42 Mass Rebuild is finished

[Fabio Valentini]

On Mon, Jan 27, 2025 at 3:32 AM Ian McInerney via devel
 wrote:
>
> Were the FTBFS bugs filed differently this time? It appears that there were 
> actually two FTBFS bugs filed against Audacity 
> (https://bugzilla.redhat.com/show_bug.cgi?id=2339522 and 
> https://bugzilla.redhat.com/show_bug.cgi?id=2339913) that both reference the 
> same Koji task, but then the first bug was marked as a duplicate of the later 
> one by releng shortly after its creation?
>
> Also, it appears that the FTBFS bugs for the mass rebuild have been linked to 
> the FTBFS tracker from F41 
> (https://bugzilla.redhat.com/show_bug.cgi?id=2260875), can this be fixed so 
> there is a FTBFS tracker for F42 separate from F41?

It was done "differently" in the sense that it was first done "wrong" :D

To my knowledge, the script that files the FTBFS bugs was first
- launched with settings to block the wrong bug (F41FTBFS),
- when this was noticed, stopped, and re-run blocking the correct F42FTBFS,
- duplicate bugs were manually closed, and had Blocks: F41FTBFS
removed from them.

So the F42FTBFS blocker bug already exists
(https://bugzilla.redhat.com/show_bug.cgi?id=F42FTBFS).
It's possible that one of your package was affected by the double-run
and wasn't "cleaned up" properly.

Fabio
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Next Open NeuroFedora Meeting: Monday, 27 January 2025 (today) at 13:00 UTC

[Ankur Sinha]

Hello everyone,

Please join us at the next Open NeuroFedora team meeting on Monday, 27
January at 13:00 UTC.  The meeting is a public meeting, and open for
everyone to attend. You can join us over on Matrix in the Fedora Meeting
channel:

https://matrix.to/#/#meeting:fedoraproject.org

You can use this link to see the local time for the meeting:

https://www.timeanddate.com/worldclock/fixedtime.html?msg=Open+NeuroFedora+Meeting&iso=20250127T13&p1=1440&ah=1

or you can use this command in a terminal:

$ date -d 'Monday, January 27, 2025 13:00 UTC'

The meeting will be chaired by @ankursinha. The agenda for the
meeting is:

- New introductions and roll call.
- Tasks from last meeting: https://meetbot.fedoraproject.org/latest/neurofedora
- Open Pagure tickets: 
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open&tags=S%3A+Next+meeting
- Package health check: 
https://packager-dashboard.fedoraproject.org/dashboard?groups=neuro-sig
- Open package reviews check: 
https://bugzilla.redhat.com/show_bug.cgi?id=fedora-neuro
- CompNeuro lab compose status check: 
https://koji.fedoraproject.org/koji/packageinfo?packageID=30691
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.

We hope to see you there!

The meeting announcement is also posted on the NeuroFedora blog here:

https://neuroblog.fedoraproject.org/2025/01/27/next-open-neurofedora-meeting-27-january-2025-1300-utc.html

You can learn more about NeuroFedora here:
https://neuro.fedoraproject.org

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
Description: PGP signature
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Strange compile error with math.h for 42

[Andrei Radchenko]

Hello,

Fedora tooling got changed [1] , probably something to do with the new
gcc15.

Andrei

[1] https://fedoraproject.org/wiki/Changes/GNUToolchainF42

On Sun, Jan 26, 2025 at 3:48 PM Ron Olson  wrote:

> Hey all-
>
> I’m trying to fix build failures for swift-lang on F42 and while I’ve
> fixed a number of places where  wasn’t explicitly defined, I’m now
> getting a strange compile error regarding math.h and cmath that I can’t
> reproduce outside of a full build:
>
>  54 | #if __has_include()
>  55 | #include 
> |  `- note: in file included from 
> /builddir/build/BUILD/swift-lang-6.0.3-build/usr/lib/swift/_FoundationCShims/_CStdlib.h:55:
>  56 | #endif
>  57 |
> /usr/lib/gcc/x86_64-redhat-linux/15/../../../../include/c++/15/math.h:36:11: 
> note: in file included from 
> /usr/lib/gcc/x86_64-redhat-linux/15/../../../../include/c++/15/math.h:36:
>  34 | #define _GLIBCXX_MATH_H 1
>  35 |
>  36 | # include 
> |   `- note: in file included from 
> /usr/lib/gcc/x86_64-redhat-linux/15/../../../../include/c++/15/math.h:36:
>  37 |
>  38 | using std::abs;
> /usr/lib/gcc/x86_64-redhat-linux/15/../../../../include/c++/15/cmath:100:3: 
> error: redefinition of 'acos'
>   98 | #ifndef __CORRECT_ISO_CPP_MATH_H_PROTO
>   99 |   inline _GLIBCXX_CONSTEXPR float
>  100 |   acos(float __x)
>  |   |- error: redefinition of 'acos'
>  |   `- note: previous definition is here
>  101 |   { return __builtin_acosf(__x); }
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=128439616
>
> What I don’t get is that it built fine before on F42/Rawhide (and uses the
> previously built swift rpm as part of its build process), so I guess I
> don’t know what changed.
>
> Thanks for any help!
>
> Ron
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC defined(__cplusplus) one rawhide

[Sérgio Basto via devel]

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
> pragma to disable the warning instead?
> 
> Another option could be to drop the CPP standard check altogether and
> rely on the availability of __has_include.
> 
> [1]: https://en.cppreference.com/w/cpp/header/ciso646

but "#include " (the replacement) already exist in CPP17 ,
isn't it ? 


-- 
Sérgio M. B.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC defined(__cplusplus) one rawhide

[Cristian Le via devel]

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
pragma to disable the warning instead?

Another option could be to drop the CPP standard check altogether and
rely on the availability of __has_include.

[1]:https://en.cppreference.com/w/cpp/header/ciso646

but "#include " (the replacement) already exist in CPP17 ,
isn't it ?


According to the standard, no it shouldn't be, but compilers often 
provide the features way before the standard [1]. Best example of this 
`#warning` or `[[deprecated]]` in C23 [2].


On the other hand, the inclusion of  with deprecation of 
 according to the documentation around it seems pretty 
straightforward, as in, there is no realistic reason not to include 
 if you already have it. The compiler should handle exposing 
the appropriate headers depending on the C++ standard option that it was 
provided. That's why getting rid of the CPP standard check there 
altogether would also make sense to me.


[1]: https://en.cppreference.com/w/cpp/compiler_support/20
[2]: https://en.cppreference.com/w/c/compiler_support/23
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Linux f42 Mass Rebuild is finished

[Kevin Fenzi]

On Mon, Jan 27, 2025 at 11:06:03AM +0100, Fabio Valentini wrote:
> On Mon, Jan 27, 2025 at 3:32 AM Ian McInerney via devel
>  wrote:
> >
> > Were the FTBFS bugs filed differently this time? It appears that there were 
> > actually two FTBFS bugs filed against Audacity 
> > (https://bugzilla.redhat.com/show_bug.cgi?id=2339522 and 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2339913) that both reference 
> > the same Koji task, but then the first bug was marked as a duplicate of the 
> > later one by releng shortly after its creation?
> >
> > Also, it appears that the FTBFS bugs for the mass rebuild have been linked 
> > to the FTBFS tracker from F41 
> > (https://bugzilla.redhat.com/show_bug.cgi?id=2260875), can this be fixed so 
> > there is a FTBFS tracker for F42 separate from F41?
> 
> It was done "differently" in the sense that it was first done "wrong" :D
> 
> To my knowledge, the script that files the FTBFS bugs was first
> - launched with settings to block the wrong bug (F41FTBFS),
> - when this was noticed, stopped, and re-run blocking the correct F42FTBFS,

Yep. Excactly right.

> - duplicate bugs were manually closed, and had Blocks: F41FTBFS
> removed from them.

Sadly the last bit isn't done yet:

https://pagure.io/releng/issue/12545

The python-bugzilla interface is being anoying removing those blocks.
If you have knowledge in this area, please do look and chime in in the
ticket. 

> So the F42FTBFS blocker bug already exists
> (https://bugzilla.redhat.com/show_bug.cgi?id=F42FTBFS).
> It's possible that one of your package was affected by the double-run
> and wasn't "cleaned up" properly.

The final cleanup is still pending. ;( 

kevin
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inadvertent mass-rebuild triggered soname bump in libnfs

[Stephen Gallagher]

On Mon, Jan 27, 2025 at 10:12 AM Vít Ondruch  wrote:

>
> Dne 27. 01. 25 v 15:58 Stephen Gallagher napsal(a):
>
>
>
> On Mon, Jan 27, 2025 at 9:40 AM Vít Ondruch  wrote:
>
>>
>> Dne 26. 01. 25 v 16:40 Stephen Gallagher napsal(a):
>>
>>
>>
>> On Sat, Jan 25, 2025 at 12:24 PM Miro Hrončok 
>> wrote:
>>
>>> On 24. 01. 25 22:13, Adam Williamson wrote:
>>> > Note that side tags aren't the only issue. Sometimes a maintainer
>>> > commits a bump to git but doesn't build it in a side tag or rawhide,
>>> > for whatever reason. Sometimes a package is*built*, but gated from
>>> > Rawhide by automated tests, but then the mass rebuild effectively
>>> > overrides the gating (we found several cases like this). Just checking
>>> > side tags isn't gonna catch everything. I really think the appropriate
>>> > check is 'was the build most recently tagged into fXX built from the
>>> > current git commit? if not, don't rebuild this package, yell for manual
>>> > intervention'.
>>>
>>> Generally, this sounds like a good idea.
>>>
>>> However, note that is is not uncommon for (proven)packagers to commit
>>> stuff
>>> that will only eventually get built. We might discover that the number
>>> of
>>> packages that we yell at for no good reason is too high.
>>>
>>> As an example of a big chnage, I think the SPDX commits were pushed but
>>> not built.
>>>
>>>
>> It's possible that I'm in the minority here, but I honestly don't think
>> anything should be pushed to dist-git unless it's intended to be built more
>> or less immediately. Yes, even changes without an immediate functional
>> impact like the SPDX changes.
>>
>>
>> I would agree with your statement if I was considering this just from
>> mass-rebuild perspective. But considering usage of those packages, I
>> believe that we should always consider the amount of updates.
>>
>> If I ignore that am Rawhide user consuming such changes, updated package
>> in Rawhide also means that maybe others mock caches will become obsolete.
>>
>
> So, in the case of Branched/Stable Fedora, we can always opt not to submit
> a Bodhi update to avoid bugging people.
>
>
> I might have lost a track already, but wasn't one of the concerns build of
> package in side-tag, which is in my understanding is similar to not
> submitting update in stable versions?
>

Addressing different personas here. I think we *should* be bothering the
maintainers to make sure they don't lose track of updates. But we don't
need to push out meaningless updates to end-users either. It's a balancing
act.

I was only originally concerning myself with Rawhide, really. And I don't
think we have enough active users (not automation) there for that to be a
real issue.



> With Rawhide's automated updates, that does indeed lead to more churn, but
> I'd argue that this is probably not a major issue. The majority of Rawhide
> usage is likely to be in CI systems rather than end-user systems (Kevin,
> myself and other insane people who run Rawhide on our primary machines
> notwithstanding).
>
> So I don't think the impact would be terrible.
>
>
>
>> That said, I agree with Kevin that we should have the compose reports
>> list anything in the compose whose state is "The commit at the HEAD of the
>> `rawhide` branch does not match the commit used for the latest build in
>> Rawhide" and treat that as a bug (ideally, we'd open one automatically)
>> that must be resolved prior to the next mass-rebuild (either by getting a
>> build done or tagging the bug in some way that indicates that it's okay for
>> the mass-rebuild to build it). Anything still on the list when the
>> mass-rebuild is ready to start should be skipped and the bug should be
>> marked as a blocker for Beta (to make sure it gets looked at). Detecting
>> this should be fairly easy, albeit adding a bit to the Koji API load.
>>
>>
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>> Do not reply to spam, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org

Re: Inadvertent mass-rebuild triggered soname bump in libnfs

[Stephen Gallagher]

On Mon, Jan 27, 2025 at 9:40 AM Vít Ondruch  wrote:

>
> Dne 26. 01. 25 v 16:40 Stephen Gallagher napsal(a):
>
>
>
> On Sat, Jan 25, 2025 at 12:24 PM Miro Hrončok  wrote:
>
>> On 24. 01. 25 22:13, Adam Williamson wrote:
>> > Note that side tags aren't the only issue. Sometimes a maintainer
>> > commits a bump to git but doesn't build it in a side tag or rawhide,
>> > for whatever reason. Sometimes a package is*built*, but gated from
>> > Rawhide by automated tests, but then the mass rebuild effectively
>> > overrides the gating (we found several cases like this). Just checking
>> > side tags isn't gonna catch everything. I really think the appropriate
>> > check is 'was the build most recently tagged into fXX built from the
>> > current git commit? if not, don't rebuild this package, yell for manual
>> > intervention'.
>>
>> Generally, this sounds like a good idea.
>>
>> However, note that is is not uncommon for (proven)packagers to commit
>> stuff
>> that will only eventually get built. We might discover that the number of
>> packages that we yell at for no good reason is too high.
>>
>> As an example of a big chnage, I think the SPDX commits were pushed but
>> not built.
>>
>>
> It's possible that I'm in the minority here, but I honestly don't think
> anything should be pushed to dist-git unless it's intended to be built more
> or less immediately. Yes, even changes without an immediate functional
> impact like the SPDX changes.
>
>
> I would agree with your statement if I was considering this just from
> mass-rebuild perspective. But considering usage of those packages, I
> believe that we should always consider the amount of updates.
>
> If I ignore that am Rawhide user consuming such changes, updated package
> in Rawhide also means that maybe others mock caches will become obsolete.
>
>
So, in the case of Branched/Stable Fedora, we can always opt not to submit
a Bodhi update to avoid bugging people. With Rawhide's automated updates,
that does indeed lead to more churn, but I'd argue that this is probably
not a major issue. The majority of Rawhide usage is likely to be in CI
systems rather than end-user systems (Kevin, myself and other insane people
who run Rawhide on our primary machines notwithstanding).

So I don't think the impact would be terrible.



> That said, I agree with Kevin that we should have the compose reports list
> anything in the compose whose state is "The commit at the HEAD of the
> `rawhide` branch does not match the commit used for the latest build in
> Rawhide" and treat that as a bug (ideally, we'd open one automatically)
> that must be resolved prior to the next mass-rebuild (either by getting a
> build done or tagging the bug in some way that indicates that it's okay for
> the mass-rebuild to build it). Anything still on the list when the
> mass-rebuild is ready to start should be skipped and the bug should be
> marked as a blocker for Beta (to make sure it gets looked at). Detecting
> this should be fairly easy, albeit adding a bit to the Koji API load.
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Additional checkpoint for major toolchain updates before mass rebuild

[Michal Schorm]

Does this RFC include an obligation for the 'major toolchain upgrades'
Fedora Change owners to rebuild the dependent packages ?

I mean - without a failed build it doesn't really make a difference to me.
FTBFS bugzilla ticket is something I note and try to solve.

However without a rebuild, the change may or may not break my packages
- no one will know until mass rebuild.
And I can hardly see myself trying to rebuild all my packages myself
1-6 days before the mass rebuild, when the mass rebuild will do that
for me.

In short:
Knowing sooner that my packages are affected will likely make me fix
them sooner.
But without knowing that, I likely won't be trying to find out myself,
when the mass rebuild will do that for me.

Michal

--

Michal Schorm
Software Engineer
Databases Team
Red Hat

--

On Mon, Jan 27, 2025 at 7:05 PM Fabio Valentini  wrote:
>
> Hi all,
>
> For reference, this has been discussed at the last FPC meeting:
> https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2025-01-23/fpc.2025-01-23-17.00.log.html
>
> And I filed a corresponding RFC with FESCo here:
> https://pagure.io/fesco/issue/3347
>
> In an effort to avoid the large amount of breakage during the mass
> rebuild that happened with GCC 15 and Go 1.24 landing only *hours*
> before it was started, we suggested the following:
>
> "Major toolchain upgrades must land at least 7 days before the
> scheduled start of the mass rebuild."
>
> This would mean either major toolchain updates would need to be pushed
> slightly earlier, or the mass rebuild is started slightly later, plus
> / minus a few days. A proposal to move the January mass rebuild back
> by two entire weeks had previously been rejected by FESCo, mostly
> because it would result in the mass rebuild (and its fallout)
> happening during FOSDEM.
>
> Making sure major toolchain updates are in place at least one week
> before the start of the mass rebuild should give maintainers more time
> to deal with potential breakage and / or give compiler maintainers
> more time to fix regressions that are only found after the update
> lands.
>
> Due to the way how release schedules line up, this additional
> "checkpoint" would mostly affect GCC and golang, but potentially also
> other major toolchains - though LLVM will likely continue to need an
> exception to allow landing the major update "very late" - because the
> LLVM release schedule doesn't line up well with the Fedora release
> schedule.
>
> There have been some comments on the FESCo ticket, but it would
> probably be better to have a discussion on the mailing list, instead.
>
> Fabio
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

RFC: Additional checkpoint for major toolchain updates before mass rebuild

[Fabio Valentini]

Hi all,

For reference, this has been discussed at the last FPC meeting:
https://meetbot.fedoraproject.org/meeting-1_matrix_fedoraproject-org/2025-01-23/fpc.2025-01-23-17.00.log.html

And I filed a corresponding RFC with FESCo here:
https://pagure.io/fesco/issue/3347

In an effort to avoid the large amount of breakage during the mass
rebuild that happened with GCC 15 and Go 1.24 landing only *hours*
before it was started, we suggested the following:

"Major toolchain upgrades must land at least 7 days before the
scheduled start of the mass rebuild."

This would mean either major toolchain updates would need to be pushed
slightly earlier, or the mass rebuild is started slightly later, plus
/ minus a few days. A proposal to move the January mass rebuild back
by two entire weeks had previously been rejected by FESCo, mostly
because it would result in the mass rebuild (and its fallout)
happening during FOSDEM.

Making sure major toolchain updates are in place at least one week
before the start of the mass rebuild should give maintainers more time
to deal with potential breakage and / or give compiler maintainers
more time to fix regressions that are only found after the update
lands.

Due to the way how release schedules line up, this additional
"checkpoint" would mostly affect GCC and golang, but potentially also
other major toolchains - though LLVM will likely continue to need an
exception to allow landing the major update "very late" - because the
LLVM release schedule doesn't line up well with the Fedora release
schedule.

There have been some comments on the FESCo ticket, but it would
probably be better to have a discussion on the mailing list, instead.

Fabio
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inadvertent mass-rebuild triggered soname bump in libnfs

[Adam Williamson]

On Sun, 2025-01-26 at 10:40 -0500, Stephen Gallagher wrote:
> Anything still on the list when the
> mass-rebuild is ready to start should be skipped and the bug should be
> marked as a blocker for Beta (to make sure it gets looked at).

Your regular reminder that this is not what the blocker process is for.
Bugs that really mean we should not do a release because it would be
bad for people who use the distribution are blockers. That's why we
look at them. Anything else is not a blocker. If something else needs
to be looked at, please invent a different process which will cause the
relevant people to look at it.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Inadvertent mass-rebuild triggered soname bump in libnfs

[Adam Williamson]

On Sun, 2025-01-26 at 10:40 -0500, Stephen Gallagher wrote:
> It's possible that I'm in the minority here, but I honestly don't think
> anything should be pushed to dist-git unless it's intended to be built more
> or less immediately. Yes, even changes without an immediate functional
> impact like the SPDX changes.

In theory I agree, but this is a theory vs. practice problem. In
practice we do mass rebuilds every six months and this happens. So in
practice we need to deal with it somehow. If you have a practical
method to prevent people committing things without 100% certainty they
will be built and tagged shortly after, great. Otherwise this isn't
useful.

Note it's difficult to have such certainty at present in e.g. the
soname bump case. Even if you do things The Right Modern Way - by
creating a pull request for the library being bumped, so tests run on
the PR before it's merged - it's not going to help, because we do not
have a mechanism for that PR to also include or be associated with PRs
for the dependent packages and for them all to be tested together, to
see if the bump really 'works'.

You *can* 'test before you merge' at present but it involves a chunk of
manual work; you'll either have to set up a side tag and do builds it
in *from a non-default branch* and then test those somehow, or use a
COPR or a local mock environment with a side repo. I think it's a bit
unrealistic to expect all packagers to do that, and clearly they don't.
What they actually do is bump the rawhide branch, build it in a
sidetag, then try and get the dependent package rebuilds done. If one
of them fails, or all the builds they try work but the update fails
testing because they missed one or there's an actual bug, we're now in
the state where the rawhide branched is out of sync with what's built
and tagged.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net




-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

GCC defined(__cplusplus) one rawhide

[Sérgio Basto via devel]

Hi,

I just want check, if I'm thinking correctly before submitting a fix in
gtest package 

The problem is on Rawhide I have this warning that make other packages
fail to build [1] 

gtest source [2] source get __cplusplus value and include  or
#include   depending on __cplusplus value .

On rawhide I got the warning on Fedora 41 don't but __cplusplus of GCC
compiler is the same (201703)

My proposal is to change the comparison from 202002L to 201703L 
-#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \
+#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \

What do you think ? 

Best regards, 

[1]
/usr/include/c++/15/ciso646:46:4: warning: #warning " is
deprecated in C++17, use  to detect implementation-specific
macros" [-Wcpp] 
46 | #  warning " is deprecated in C++17, use
 to detect implementation-specific macros"
   |^~~

[2]
https://github.com/google/googletest/blob/main/googletest/include/gtest/internal/gtest-port.h#L274

// Detect C++ feature test macros as gracefully as possible.
// MSVC >= 19.15, Clang >= 3.4.1, and GCC >= 4.1.2 support feature test macros.
#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \
(!defined(__has_include) || GTEST_INTERNAL_HAS_INCLUDE())
#include   // C++20 and later
#elif (!defined(__has_include) || GTEST_INTERNAL_HAS_INCLUDE())
#include   // Pre-C++20
#endif

[3]
#include 

int main() {
std::cout << "__cplusplus: " << __cplusplus << std::endl;
return 0;
}

g++ check_cpp_version.cpp -o check_cpp_version && ./check_cpp_version
__cplusplus: 201703



-- 
Sérgio M. B.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Additional checkpoint for major toolchain updates before mass rebuild

[Fabio Valentini]

On Mon, Jan 27, 2025 at 8:02 PM Michal Schorm  wrote:
>
> Does this RFC include an obligation for the 'major toolchain upgrades'
> Fedora Change owners to rebuild the dependent packages ?

No, but this is already happening to some degree.
For example, test builds with GCC snapshots were actually happening,
but the results were not communicated to package maintainers before
the mass rebuild had started - and then it was too late. Making sure
that the toolchain is in Rawhide one week *before* the mass rebuild
starts would give a bigger window for that to happen.

Fabio
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC defined(__cplusplus) one rawhide

[Cristian Le via devel]

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 
the availability of __has_include.

[1]: https://en.cppreference.com/w/cpp/header/ciso646

On 27 January 2025 20:31:35 CET, "Sérgio Basto via devel" 
 wrote:
>Hi,
>
>I just want check, if I'm thinking correctly before submitting a fix in
>gtest package 
>
>The problem is on Rawhide I have this warning that make other packages
>fail to build [1] 
>
>gtest source [2] source get __cplusplus value and include  or
>#include   depending on __cplusplus value .
>
>On rawhide I got the warning on Fedora 41 don't but __cplusplus of GCC
>compiler is the same (201703)
>
>My proposal is to change the comparison from 202002L to 201703L 
>-#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \
>+#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \
>
>What do you think ? 
>
>Best regards, 
>
>[1]
>/usr/include/c++/15/ciso646:46:4: warning: #warning " is
>deprecated in C++17, use  to detect implementation-specific
>macros" [-Wcpp] 
>46 | #  warning " is deprecated in C++17, use
> to detect implementation-specific macros"
>   |^~~
>
>[2]
>https://github.com/google/googletest/blob/main/googletest/include/gtest/internal/gtest-port.h#L274
>
>// Detect C++ feature test macros as gracefully as possible.
>// MSVC >= 19.15, Clang >= 3.4.1, and GCC >= 4.1.2 support feature test macros.
>#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \
>(!defined(__has_include) || GTEST_INTERNAL_HAS_INCLUDE())
>#include   // C++20 and later
>#elif (!defined(__has_include) || GTEST_INTERNAL_HAS_INCLUDE())
>#include   // Pre-C++20
>#endif
>
>[3]
>#include 
>
>int main() {
>std::cout << "__cplusplus: " << __cplusplus << std::endl;
>return 0;
>}
>
>g++ check_cpp_version.cpp -o check_cpp_version && ./check_cpp_version
>__cplusplus: 201703
>
>
>
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Additional checkpoint for major toolchain updates before mass rebuild

[Michal Schorm]

Alright, thanks for the explanation.

In that case, I think the RFC is a step in the right direction,
but I don't see it being useful, unless the change owners do the extra
step and file the FTBFS bugs to notify the maintainers.
They can do it already, but don't. Making them finish the change
sooner IMO won't make them to also create the tickets.

In general, I'd like to see any change owner to be responsible for
dependent package breakages to at least the degree of notifying the
maintainer by filling the FTBFS ticket.
Huge sets of wildly interconnected packages are one of the cores of
any distribution, and thoughtfulness is necessary.

--

Michal Schorm
Software Engineer
Databases Team
Red Hat

--

On Mon, Jan 27, 2025 at 8:18 PM Fabio Valentini  wrote:
>
> On Mon, Jan 27, 2025 at 8:02 PM Michal Schorm  wrote:
> >
> > Does this RFC include an obligation for the 'major toolchain upgrades'
> > Fedora Change owners to rebuild the dependent packages ?
>
> No, but this is already happening to some degree.
> For example, test builds with GCC snapshots were actually happening,
> but the results were not communicated to package maintainers before
> the mass rebuild had started - and then it was too late. Making sure
> that the toolchain is in Rawhide one week *before* the mass rebuild
> starts would give a bigger window for that to happen.
>
> Fabio
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Schedule for Tuesday's FESCo Meeting (2025-01-28)

[Fabio Alessandro Locati via devel]

Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00 UTC in #meeting:fedoraproject.org
on Matrix.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2025-01-28 17:00 UTC'

Links to all issues to be discussed can be found at: 
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#3328 Update Policy Exception Request: libdisplay-info 
https://pagure.io/fesco/issue/3328
APPROVED (+6, 0, 0)

#3329 mupdf: update policy exception request
https://pagure.io/fesco/issue/3329
APPROVED (+8, 0, 0)

#3334 Change: Django 5x 
https://pagure.io/fesco/issue/3334
APPROVED (+8, 0, 0)

#3335 Change: GNOME Shell extension Dependency Generator 
https://pagure.io/fesco/issue/3335
APPROVED (+6, 1, 0)

#3336 Change: Protobuf 5.x/6.x 
https://pagure.io/fesco/issue/3336
APPROVED (+8, 0, 0)

#3337 Change: Deprecate python-pytest-runner
https://pagure.io/fesco/issue/3337
APPROVED (+7, 0, 0)

#3339 Change: Retire PyO3 v0.19, v0.20 and v0.21
https://pagure.io/fesco/issue/3339
APPROVED (+8, 0, 0)

#3341 Change: Koji uses Red Hat Image Builder locally
https://pagure.io/fesco/issue/3341
APPROVED (+8, 0, 0)

#3344 Change: Unification of boot loader updates, phase 1
https://pagure.io/fesco/issue/3344
APPROVED (+6, 0, 0)

#3327 Update Policy Exception Request: kdecoration
https://pagure.io/fesco/issue/3327
APPROVED (+7, 0, 0)

= Followups =

N/A

= New business =

#3293 Change: Dropping of cert.pem file
https://pagure.io/fesco/issue/3293

#3338 Change: Deprecation of STI Tests
https://pagure.io/fesco/issue/3338

#3343 Change: Trafficserver 10.0
https://pagure.io/fesco/issue/3343

= Open Floor = 

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting. 

-- 
Fabio Alessandro "Fale" Locati
fale.io
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: RFC: Additional checkpoint for major toolchain updates before mass rebuild

[Siddhesh Poyarekar]

On 2025-01-27 14:55, Michal Schorm wrote:

Alright, thanks for the explanation.

In that case, I think the RFC is a step in the right direction,
but I don't see it being useful, unless the change owners do the extra
step and file the FTBFS bugs to notify the maintainers.
They can do it already, but don't. Making them finish the change
sooner IMO won't make them to also create the tickets.

In general, I'd like to see any change owner to be responsible for
dependent package breakages to at least the degree of notifying the
maintainer by filling the FTBFS ticket.
Huge sets of wildly interconnected packages are one of the cores of
any distribution, and thoughtfulness is necessary.


Like Fabio mentioned, we already do this and tend to have that 
information but don't communicate until we have determined that it is 
relevant and as it happened this time around, it was too late.  The main 
reason why we hold on to the information is that we want to avoid 
bothering package maintainers until we have understood the failures to 
be due to, e.g. new diagnostics but maybe it's better to communicate 
earlier and it be punted back to gcc than to wait too long to 
communicate the issue.


As I mentioned in the Fesco issue, I reckon it's far more useful to have 
a change checkpoint even earlier (~ a month before mass rebuild) where 
we publish our mass *prebuild* results (we do this in December) for a 
gcc and instead of waiting to sift through the results ourselves, we 
file FTBFS bugs right away so that package maintainers have visibility 
to the failures.  Having the toolchain update in rawhide should maybe 
then be a less important checkpoint.


Thanks,
Sid

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora eln compose report: 20250128.n.0 changes

[Fedora ELN Report]

OLD: Fedora-eln-20250127.n.0
NEW: Fedora-eln-20250128.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  134
Dropped packages:0
Upgraded packages:   6
Downgraded packages: 0

Size of added packages:  187.76 MiB
Size of dropped packages:0 B
Size of upgraded packages:   322.27 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   29.50 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: atop-2.11.0-1.eln144
Summary: An advanced interactive monitor to view the load on system and process 
level
RPMs:atop
Size:930.19 KiB

Package: ccache-4.10.2-2.eln145
Summary: C/C++ compiler cache
RPMs:ccache
Size:2.55 MiB

Package: clamav-1.4.1-1.eln144
Summary: End-user tools for the Clam Antivirus scanner
RPMs:clamav-lib
Size:13.11 MiB

Package: colm-0.14.7-9.eln145
Summary: Programming language designed for the analysis of computer languages
RPMs:colm colm-devel
Size:3.21 MiB

Package: ctags-6.1.0-2.eln145
Summary: A C programming language indexing and/or cross-reference tool
RPMs:ctags
Size:3.45 MiB

Package: dash-0.5.12-5.eln145
Summary: Small and fast POSIX-compliant shell
RPMs:dash
Size:402.70 KiB

Package: dbench-4.0-33.eln145
Summary: Filesystem load benchmarking tool
RPMs:dbench
Size:2.44 MiB

Package: debian-keyring-2023.4-5.eln145
Summary: GnuPG archive keys of the Debian archive
RPMs:debian-keyring
Size:109.45 KiB

Package: debootstrap-1.0.137-1.eln144
Summary: Debian GNU/Linux bootstrapper
RPMs:debootstrap
Size:91.94 KiB

Package: dpkg-1.22.11-2.eln145
Summary: Package maintenance system for Debian Linux
RPMs:dpkg
Size:6.18 MiB

Package: duo_unix-1.12.1-12.eln145
Summary: Duo two-factor authentication for UNIX systems
RPMs:duo_unix duo_unix-selinux pam_duo
Size:521.08 KiB

Package: et-6.2.8-5.eln145
Summary: Remote shell that survives IP roaming and disconnect
RPMs:et
Size:5.23 MiB

Package: fedora-license-data-1.64-2.eln145
Summary: Fedora Linux license data
RPMs:fedora-license-data
Size:141.65 KiB

Package: fping-5.3-3.eln145
Summary: Scriptable, parallelized ping-like utility
RPMs:fping
Size:174.13 KiB

Package: git-filter-repo-2.38.0-9.eln145
Summary: Quickly rewrite git repository history (git-filter-branch replacement)
RPMs:git-filter-repo
Size:197.49 KiB

Package: hiredis-1.2.0-6.eln145
Summary: Minimalistic C client library for Redis
RPMs:hiredis
Size:202.55 KiB

Package: html401-dtds-4.01-19991224.12.eln145.26
Summary: HTML 4.01 document type definitions
RPMs:html401-dtds
Size:26.50 KiB

Package: htop-3.3.0-7.eln145
Summary: Interactive process viewer
RPMs:htop
Size:823.39 KiB

Package: iotools-1.7~pre0-12.eln145
Summary: Set of command line tools to access hardware device registers
RPMs:iotools
Size:131.91 KiB

Package: keyrings-filesystem-1-23.eln145
Summary: Keyrings filesystem layout
RPMs:keyrings-filesystem
Size:7.84 KiB

Package: libcdson-1.0.0-8.eln145
Summary: Pure C parsing/serialization for the DSON data format, for humans
RPMs:libcdson
Size:101.15 KiB

Package: libdwarf-1:0.11.1-3.eln145
Summary: Library to access the DWARF Debugging file format
RPMs:libdwarf libdwarf-devel
Size:5.82 MiB

Package: libidn-1.42-5.eln145
Summary: Internationalized Domain Name support library
RPMs:libidn libidn-devel
Size:1.18 MiB

Package: libmd-1.1.0-7.eln145
Summary: Library that provides message digest functions from BSD systems
RPMs:libmd
Size:181.49 KiB

Package: libvterm-0.3.3-5.eln145
Summary: An abstract library implementation of a VT220/xterm/ECMA-48 terminal 
emulator
RPMs:libvterm
Size:184.41 KiB

Package: linux-sysinfo-snapshot-3.7.8.2-2.eln145
Summary: System information snapshot tool for Mellanox adapters
RPMs:linux-sysinfo-snapshot
Size:58.39 KiB

Package: lua-lpeg-1.1.0-5.eln145
Summary: Parsing Expression Grammars for Lua
RPMs:lua5.1-lpeg
Size:152.14 KiB

Package: lua-luv-1.48.0.2-3.eln145
Summary: Bare libuv bindings for lua
RPMs:libluv lua5.1-luv luajit2.1-luv
Size:572.24 KiB

Package: mkosi-25.1-1.eln145
Summary: Create bespoke OS images
RPMs:mkosi
Size:642.02 KiB

Package: mlnx-tools-23.07-6.eln145
Summary: Mellanox userland tools and scripts
RPMs:mlnx-tools
Size:90.53 KiB

Package: mosh-1.4.0-8.eln145
Summary: Mobile shell that supports roaming and intelligent local echo
RPMs:mosh
Size:999.76 KiB

Package: msgpack-3.1.0-18.eln145
Summary: Binary-based efficient object serialization library
RPMs:msgpack
Size:122.13 KiB

Package: msr-tools-1.3-29.eln145
Summary: Collection of tools for reading/writing CPU model specific registers
RPMs:msr-tools
Size:20.10 KiB

Package: ncdu-1.21-1.eln144
Summary: Text-based disk usage viewer
RPMs:ncdu
Size:249.82 KiB

Package: ncurses

Re: GCC __cplusplus definition on rawhide

[Sérgio Basto via devel]

On Mon, 2025-01-27 at 19:31 +, Sérgio Basto via devel wrote:
> Hi,
> 
> I just want check, if I'm thinking correctly before submitting a fix
> in
> gtest package 
> 
> The problem is on Rawhide I have this warning that make other
> packages
> fail to build [1] 
> 
> gtest source [2] source get __cplusplus value and include 
> or
> #include   depending on __cplusplus value .
> 
> 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 202002 ? 


> My proposal is to change the comparison from 202002L to 201703L 
> -#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \
> +#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \
> 
> What do you think ? 
> 
> Best regards, 
> 
> [1]
> /usr/include/c++/15/ciso646:46:4: warning: #warning " is
> deprecated in C++17, use  to detect implementation-specific
> macros" [-Wcpp] 
>     46 | #  warning " is deprecated in C++17, use
>  to detect implementation-specific macros"
>    |    ^~~
> 
> [2]
> https://github.com/google/googletest/blob/main/googletest/include/gtest/internal/gtest-port.h#L274
> 
> // Detect C++ feature test macros as gracefully as possible.
> // MSVC >= 19.15, Clang >= 3.4.1, and GCC >= 4.1.2 support feature
> test macros.
> #if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \
>     (!defined(__has_include) ||
> GTEST_INTERNAL_HAS_INCLUDE())
> #include   // C++20 and later
> #elif (!defined(__has_include) ||
> GTEST_INTERNAL_HAS_INCLUDE())
> #include   // Pre-C++20
> #endif
> 
> [3]
> #include 
> 
> int main() {
>     std::cout << "__cplusplus: " << __cplusplus << std::endl;
>     return 0;
> }
> 
> g++ check_cpp_version.cpp -o check_cpp_version && ./check_cpp_version
> __cplusplus: 201703
> 
> 
> 
> -- 
> Sérgio M. B.

-- 
Sérgio M. B.
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: GCC __cplusplus definition on rawhide

[Cristian Le via devel]

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 202002 ? 

Depends on the -std flag used [1]. And the change with gcc15 on rawhide should 
be a default of -std=c++17 if no flag is passed. 

[1]: https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
-- 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue