Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Jonathan Wakely]

On Tue, 2 Apr 2024 at 19:44, Richard Hughes  wrote:
>
> On Tue, 2 Apr 2024 at 10:40, Aoife Moloney  wrote:
> > Switch the default desktop experience for Workstation to KDE Plasma.
> > The GNOME desktop is moved to a separate spin / edition, retaining
> > release-blocking status.
>
> If this is an April fools joke -- it's a weird one, and a day too late.

Well it was added to the wiki yesterday, but only picked up by Aoife today.
--
___
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Jonathan Wakely]

On Tue, 20 Feb 2024 at 14:55, Kevin Kofler via devel
 wrote:
>
> I have just found another essential feature that is missing in Plasma
> Wayland:

The big one for me is that Synergy and similar tools barrier and
input-leap don't work under Wayland. I don't see that mentioned at
https://community.kde.org/Plasma/Wayland_Known_Significant_Issues

My understanding is that it's now possible using libEI, but only Gnome
makes use of that. Support for KDE is tracked by
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/12 but
doesn't look close to being ready.
--
___
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: HELP! What's up with OpenVDB?

[Jonathan Wakely]

On Mon, 29 Jan 2024 at 13:03, Richard Shaw  wrote:
>
> On Mon, Jan 29, 2024 at 4:16 AM Jonathan Wakely  wrote:
>>
>> On Sun, 28 Jan 2024 at 15:18, Richard Shaw  wrote:
>> >
>> > Well I upped the memory to 10GB and got it to build but the issue on i686 
>> > with the wrong tbb package being pulled in has not been corrected by any 
>> > of the 4 maintainers of the package.
>>
>> I fixed tbb to stop installing tbb32.pc so the underlying cause should
>> be fixed in tbb-2021.11.0-5.fc40 and rebuilding openvdb should get the
>> right tbb now.
>
>
> Not sure why it didn't work then, but it doesn't change the fact that the BR 
> hadn't been updated in a very long time, using version 3 instead of date type 
> release format. The last standard version release was 4.4 in 2016.

Doh, I thought I'd already waived the gating CI failures for
tbb-2021.11.0-5 but I hadn't. I've done it now:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-115f00ec5c
The annocheck failures will be addressed ASAP.


>
> More than likely all of the BRs need a refresh to the cmake format if it's 
> supported by the package.
>
> Thanks,
> Richard
> --
> ___
> 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: SWIG 4.2 Python transition

[Jonathan Wakely]

On Fri, 26 Jan 2024 at 12:29, Florian Weimer wrote:
> In the past, this kind of problem would have just compiled and resulted
> in a run-time error when the Python extension module is loaded.  In some
> cases, issues went completely unnoticed because the Python bindins were
> unused.  But with GCC 14, it is necessary to fix calls to undeclared
> functions.

Thanks, this is a great example of why diagnostics like that should be
errors by default.
--
___
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: HELP! What's up with OpenVDB?

[Jonathan Wakely]

On Sun, 28 Jan 2024 at 15:18, Richard Shaw  wrote:
>
> Well I upped the memory to 10GB and got it to build but the issue on i686 
> with the wrong tbb package being pulled in has not been corrected by any of 
> the 4 maintainers of the package.

I fixed tbb to stop installing tbb32.pc so the underlying cause should
be fixed in tbb-2021.11.0-5.fc40 and rebuilding openvdb should get the
right tbb now.


> So I did a minimal update and changed the tbb BR's from pkgconf to cmake and 
> a scratch build completed pulling in the correct tbb-devel on i686, but now 
> two attempts at real builds fail...
>
> I think it's time to retire openvdb on i686 but blender and prusa-slicer 
> would need to stop building for i686 first as first level BRs, I didn't dig 
> any deeper into the dependency chain.
>
> Thanks,
> Richard
> --
> ___
> 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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Mon, 22 Jan 2024 at 13:24, Jonathan Wakely  wrote:
>
> On Sun, 21 Jan 2024 at 12:10, Dominik 'Rathann' Mierzejewski wrote:
> >
> > On Saturday, 20 January 2024 at 17:59, Tom Hughes via devel wrote:
> > > On 20/01/2024 16:07, Jerry James wrote:
> > >
> > > > Upstream has this in src/tbb/CMakeLists.txt:
> > > >
> > > > if (CMAKE_SIZEOF_VOID_P EQUAL 8)
> > > >  set(TBB_PC_NAME tbb)
> > > > else()
> > > >  set(TBB_PC_NAME tbb32)
> > > > endif()
> > > >
> > > > That makes the pkgconfig file install as tbb32.pc.  I don't know why
> > > > upstream is doing that.  Maybe so 64-bit and 32-bit installs can
> > > > coexist on the same system?
> > >
> > > The correct way to do that is to install in /usr/lib{,64}/pkgconfig
> > > instead of /usr/share/pkgconfig I think?
>
> Thanks. It's already in /usr/lib/pkgconfig anyway, so it looks like
> the tbb32.pc name is just unnecessary.
>
> I'll try a mock build with it renamed.

I've pushed a fix for this to rawhide, thanks for the help. The mass
rebuild hasn't got to tbb yet, so I've started a new build. When that
finishes it should be possible to un-break openvdb.
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Sun, 21 Jan 2024 at 12:10, Dominik 'Rathann' Mierzejewski wrote:
>
> On Saturday, 20 January 2024 at 17:59, Tom Hughes via devel wrote:
> > On 20/01/2024 16:07, Jerry James wrote:
> >
> > > Upstream has this in src/tbb/CMakeLists.txt:
> > >
> > > if (CMAKE_SIZEOF_VOID_P EQUAL 8)
> > >  set(TBB_PC_NAME tbb)
> > > else()
> > >  set(TBB_PC_NAME tbb32)
> > > endif()
> > >
> > > That makes the pkgconfig file install as tbb32.pc.  I don't know why
> > > upstream is doing that.  Maybe so 64-bit and 32-bit installs can
> > > coexist on the same system?
> >
> > The correct way to do that is to install in /usr/lib{,64}/pkgconfig
> > instead of /usr/share/pkgconfig I think?

Thanks. It's already in /usr/lib/pkgconfig anyway, so it looks like
the tbb32.pc name is just unnecessary.

I'll try a mock build with it renamed.
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Sat, 20 Jan 2024 at 15:10, Ben Beasley  wrote:
>
> It looks like openvdb-devel manages to accidentally depend on the tbb compat 
> package on i686 only, which breaks OpenImageIO because OpenImageIO depends on 
> the updated tbb, and that conflicts with the compat package:
>
> Problem: package tbb2020.3-devel-2020.3-3.fc40.i686 conflicts with tbb-devel 
> provided by tbb-devel-2021.11.0-2.fc40.i686
>   - package openvdb-devel-11.0.0-2.fc40.i686 requires pkgconfig(tbb) >= 3.0, 
> but none of the providers can be installed
>   - conflicting requests
>
> This is because openvdb-devel Requires pkgconfig(tbb), but on i686 the 
> current tbb-devel provides only pkgconfig(tbb32), not pkgconfig(tbb).

Aha, thanks for figuring that out! The problem was also observed at
https://bugzilla.redhat.com/show_bug.cgi?id=2036372#c43 but I didn't
get the right explanation.

I'm not sure why the i686 package does that, maybe Jerry knows (I used
his TBB COPR for the new tbb.spec).


> The best and simplest fix is probably to adjust openvdb-devel so it Requires 
> cmake(TBB) instead, which works on all architectures and is more technically 
> accurate anyway. However, I haven’t attempted to actually implement this fix.
>
> This issue breaks the dependency chain openvdb → OpenImageIO → 
> openshadinglanguage → usd → blender, which is the reason (or at least the 
> initial/primary reason?) Blender failed in the mass rebuild[1].

CC Richard Shaw who was puzzled by the same thing.

> I’m posting about this in part just to explain the problem in case anyone 
> else is encountering something similar.
>
> – Ben Beasley (FAS music)
>
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=111976337
>
>
> On 1/19/24 07:45, Jonathan Wakely wrote:
>
> On Fri, 19 Jan 2024 at 01:27, Sérgio Basto  wrote:
>
> On Fri, 2024-01-19 at 00:21 +, Jonathan Wakely wrote:
>
> On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely 
> wrote:
>
> On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely 
> wrote:
>
> I'll be building boost, tbb, and the packages that depend on them
> in
> the f40-build-side-81691
> side tag over the next few hours (in advance of the mass rebuild
> tomorrow).
>
> If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> don't rebuild it in rawhide, we're building it in the side tag
> and
> will merge it back to rawhide. If you need to update your package
> before the mass rebuild, please let me and Patrick (CC'd) know
> and
> your changes can be built in the side tag too.
>
> Please DO NOT build your package in rawhide if we're rebuilding it
> in
> the boost side tag. It will require another rebuild in the side tag
> and another bodhi update and delay the mass rebuild by several more
> hours while the gating tests run.
>
> OK, the side tag has been merged. Builds can be done in rawhide again
> now.
>
> not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
> needs pass in all "Test Gating" or is running again "Test Gating" for
> new build(s)
>
> (The new build that I think you caused btw!)
>
> I'm not sure what's going on with the waiting status, but it's in
> stable, and the new packages are in the buildroot and being used by
> the mass rebuild.
> --
> ___
> 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
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Fri, 19 Jan 2024 at 01:27, Sérgio Basto  wrote:
>
> On Fri, 2024-01-19 at 00:21 +, Jonathan Wakely wrote:
> > On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely 
> > wrote:
> > >
> > > On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely 
> > > wrote:
> > > >
> > > > I'll be building boost, tbb, and the packages that depend on them
> > > > in
> > > > the f40-build-side-81691
> > > > side tag over the next few hours (in advance of the mass rebuild
> > > > tomorrow).
> > > >
> > > > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > > > don't rebuild it in rawhide, we're building it in the side tag
> > > > and
> > > > will merge it back to rawhide. If you need to update your package
> > > > before the mass rebuild, please let me and Patrick (CC'd) know
> > > > and
> > > > your changes can be built in the side tag too.
> > >
> > > Please DO NOT build your package in rawhide if we're rebuilding it
> > > in
> > > the boost side tag. It will require another rebuild in the side tag
> > > and another bodhi update and delay the mass rebuild by several more
> > > hours while the gating tests run.
> >
> > OK, the side tag has been merged. Builds can be done in rawhide again
> > now.
>
>
> not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
> needs pass in all "Test Gating" or is running again "Test Gating" for
> new build(s)

(The new build that I think you caused btw!)

I'm not sure what's going on with the waiting status, but it's in
stable, and the new packages are in the buildroot and being used by
the mass rebuild.
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely  wrote:
>
> On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely  wrote:
> >
> > I'll be building boost, tbb, and the packages that depend on them in
> > the f40-build-side-81691
> > side tag over the next few hours (in advance of the mass rebuild tomorrow).
> >
> > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > don't rebuild it in rawhide, we're building it in the side tag and
> > will merge it back to rawhide. If you need to update your package
> > before the mass rebuild, please let me and Patrick (CC'd) know and
> > your changes can be built in the side tag too.
>
> Please DO NOT build your package in rawhide if we're rebuilding it in
> the boost side tag. It will require another rebuild in the side tag
> and another bodhi update and delay the mass rebuild by several more
> hours while the gating tests run.

OK, the side tag has been merged. Builds can be done in rawhide again now.
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely  wrote:
>
> I'll be building boost, tbb, and the packages that depend on them in
> the f40-build-side-81691
> side tag over the next few hours (in advance of the mass rebuild tomorrow).
>
> If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> don't rebuild it in rawhide, we're building it in the side tag and
> will merge it back to rawhide. If you need to update your package
> before the mass rebuild, please let me and Patrick (CC'd) know and
> your changes can be built in the side tag too.

Please DO NOT build your package in rawhide if we're rebuilding it in
the boost side tag. It will require another rebuild in the side tag
and another bodhi update and delay the mass rebuild by several more
hours while the gating tests run.
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Thu, 18 Jan 2024 at 22:15, Jonathan Wakely  wrote:
> heaptrack
> Could NOT find Libunwind (missing: LIBUNWIND_HAS_UNW_BACKTRACE)

This one's already fixed in dist-git! (thanks, aleasto)
--
___
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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely  wrote:
>
> I'll be building boost, tbb, and the packages that depend on them in
> the f40-build-side-81691
> side tag over the next few hours (in advance of the mass rebuild tomorrow).
>
> If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> don't rebuild it in rawhide, we're building it in the side tag and
> will merge it back to rawhide. If you need to update your package
> before the mass rebuild, please let me and Patrick (CC'd) know and
> your changes can be built in the side tag too.
>
> (Since there is overlap between the packages that depend on boost and
> tbb I'm doing them all at once)
> https://fedoraproject.org/wiki/Changes/F40Boost183
> https://fedoraproject.org/wiki/Changes/F39TBB2020.3

Most of the packages have now been rebuilt and will be merged to
rawhide soon (I hope!).
See https://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2

The following packages failed to build, for the reasons shown. Some
other packages that depend on these ones couldn't be built due to
these failures. There are some others that weren't rebuild, like
OpenImageIO and python-graph-tool, but the maintainers are aware.

root
unit tests 213 - gtest-math-matrix-test-testMatrixTSparse (Failed)

0ad
../../contrib/libzip/mkstemp.c:76:15: error: implicit declaration of
function ‘getpid’ [-Wimplicit-function-declaration]

botan
unit tests fail?

codeblocks
needs non-existent squirrel-devel.i686

easystroke
cellrenderertextish.c:422:56: error: assignment to ...
[-Wincompatible-pointer-types]

espresso
unit tests fail?

galera
Errors while running CTest

glob2
scons-3: command not found

gnucash
gnucash-5.5/redhat-linux-build/bindings/python/gnucash_core.c: error:
-Wno-implicit-int detected - is this intentional ? [-Werror]

heaptrack
Could NOT find Libunwind (missing: LIBUNWIND_HAS_UNW_BACKTRACE)

libpst
configure: error: cannot import Python module "distutils".

libzypp
libzypp-17.31.8/zypp-curl/proxyinfo/proxyinfolibproxy.h:18:10: fatal
error: proxy.h: No such file or directory

nextpnr
gui/quadtree.h:228:20: error: assignment of read-only member

osmium-tool
rapidjson/document.h:319:82: error: assignment of read-only member
‘rapidjson::GenericStringRef::length’

prusa-slicer
PrusaSlicer-version_2.4.2/src/slic3r/GUI/Plater.cpp:5128:21: error:
call of overloaded ‘load_files()’ is
ambiguous

slic3r
The package does -std=c++NN -U__STRICT_ANSI__ which is dumb and
doesn't work. Just use -std=gnu++NN instead, which actually works.
bits/c++config.h:2509:2: warning: #warning "__STRICT_ANSI__ seems to
have been undefined; this is not supported" [-Wcpp]

systemtap
new GCC warnings promoted to errors with -Werror

vtk
linker error: "defined in discarded section"
--
___
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-packaging] BuildrootError: could not init mock buildroot ... see root.log ...

[Jonathan Wakely]

On Thu, 18 Jan 2024 at 06:43, Mamoru TASAKA  wrote:
>
> Brad Bell wrote on 2024/01/18 14:00:
> > I got the Result in the subject above for the following build:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=111912575
> >
> > Looking at the corresponding root.log
> > https://kojipkgs.fedoraproject.org//work/tasks/2575/111912575/root.log
> > does not indicate to me what went wrong or how I should proceed ?
> > --
> > ___
>
> Looking at root.log:
>
> x86_64 (successful)
> https://kojipkgs.fedoraproject.org//work/tasks/2577/111912577/root.log
>
> DEBUG util.py:558:  Executing command: ['/bin/mount', '-n', '-o', 
> 'remount,private,rbind', '--target', 
> '/var/lib/mock/f40-build-48240062-5748626-bootstrap/root/var/lib/mock/f40-build-48240062-5748626/root']
>  with env {'TERM': 'vt100', 'SHELL': '/bin/sh', 'HOME': '/builddir', 
> 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 
> 'C.UTF-8'} and shell False
> DEBUG util.py:610:  Child return code was: 0
> DEBUG file_util.py:18:  ensuring that dir exists: 
> /var/lib/mock/f40-build-48240062-5748626/root/installation-homedir
> DEBUG file_util.py:21:  created dir: 
> /var/lib/mock/f40-build-48240062-5748626/root/installation-homedir
> DEBUG package_manager.py:289:  ['/usr/bin/dnf5', '--installroot', 
> '/var/lib/mock/f40-build-48240062-5748626/root/', 'group', 'install', 
> 'build', '--setopt=deltarpm=False', '--setopt=allow_vendor_change=yes']
> DEBUG util.py:636:  child environment: None
> DEBUG util.py:553:  Using nspawn with args ['--capability=cap_ipc_lock', 
> '--bind=/tmp/mock-resolv.fdt5pbne:/etc/resolv.conf']
> DEBUG util.py:558:  Executing command: ['/usr/bin/systemd-nspawn', '-q', 
> '-M', '69286198251d4cbebe3bbba5ac862e76', '-D', 
> '/var/lib/mock/f40-build-48240062-5748626-bootstrap/root', '-a', 
> '--capability=cap_ipc_lock', 
> '--bind=/tmp/mock-resolv.fdt5pbne:/etc/resolv.conf', '--console=pipe', 
> '--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', 
> '--setenv=HOME=/var/lib/mock/f40-build-48240062-5748626/root/installation-homedir',
>  '--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin', 
> '--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"', 
> '--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=C.UTF-8', 
> '--setenv=LC_MESSAGES=C.UTF-8', '--resolv-conf=off', '/usr/bin/dnf5', 
> '--installroot', '/var/lib/mock/f40-build-48240062-5748626/root/', 'group', 
> 'install', 'build', '--setopt=deltarpm=False', 
> '--setopt=allow_vendor_change=yes', '--setopt=tsflags=nocontexts'] with env 
> {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': 
> '/var/lib/mock/f40-build-48240062-5748626/root/installation-homedir', 
> 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 
> 'PROMPT_COMMAND': 'printf "\\033]0;\\007"', 'PS1': 
> ' \\s-\\v\\$ ', 'LANG': 'C.UTF-8', 'LC_MESSAGES': 'C.UTF-8', 
> 'SYSTEMD_NSPAWN_TMPFS_TMP': '0', 'SYSTEMD_SECCOMP': '0'} and shell False
> DEBUG util.py:463:  Updating and loading repositories:
> DEBUG util.py:463:   build  100% |  97.2 
> MiB/s |  17.6 MiB |  00m00s
>
> i686 (failing)
> https://kojipkgs.fedoraproject.org//work/tasks/2575/111912575/root.log
>
> DEBUG util.py:558:  Executing command: ['/bin/mount', '-n', '-o', 
> 'remount,private,rbind', '--target', 
> '/var/lib/mock/f40-build-48240060-5748626-bootstrap/root/var/lib/mock/f40-build-48240060-5748626/root']
>  with env {'TERM': 'vt100', 'SHELL': '/bin/sh', 'HOME': '/builddir', 
> 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 
> 'C.UTF-8'} and shell False
> DEBUG util.py:610:  Child return code was: 0
> DEBUG file_util.py:18:  ensuring that dir exists: 
> /var/lib/mock/f40-build-48240060-5748626/root/installation-homedir
> DEBUG file_util.py:21:  created dir: 
> /var/lib/mock/f40-build-48240060-5748626/root/installation-homedir
> DEBUG package_manager.py:289:  ['/usr/bin/dnf5', '--installroot', 
> '/var/lib/mock/f40-build-48240060-5748626/root/', 'group', 'install', 
> 'build', '--setopt=deltarpm=False', '--setopt=allow_vendor_change=yes', 
> '--allowerasing'] 
> <=
> DEBUG util.py:636:  child environment: None
> DEBUG util.py:553:  Using nspawn with args ['--capability=cap_ipc_lock', 
> '--bind=/tmp/mock-resolv.4fqzpd1k:/etc/resolv.conf']
> DEBUG util.py:558:  Executing command: ['/usr/bin/systemd-nspawn', '-q', 
> '-M', '41961b9ee3b140eda2ee2c91559a676a', '-D', 
> '/var/lib/mock/f40-build-48240060-5748626-bootstrap/root', '-a', 
> '--capability=cap_ipc_lock', 
> '--bind=/tmp/mock-resolv.4fqzpd1k:/etc/resolv.conf', '--console=pipe', 
> '--setenv=TERM=vt100', '--setenv=SHELL=/bin/bash', 
> '--setenv=HOME=/var/lib/mock/f40-build-48240060-5748626/root/installation-homedir',
>  '--setenv=HOSTNAME=mock', '--setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin', 
> '--setenv=PROMPT_COMMAND=printf "\\033]0;\\007"', 
> '--setenv=PS1= \\s-\\v\\$ ', '--setenv=LANG=C.UTF-8', 
> 

HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

I'll be building boost, tbb, and the packages that depend on them in
the f40-build-side-81691
side tag over the next few hours (in advance of the mass rebuild tomorrow).

If your package gets a "Rebuilt for Boost 1.83.0" comment, please
don't rebuild it in rawhide, we're building it in the side tag and
will merge it back to rawhide. If you need to update your package
before the mass rebuild, please let me and Patrick (CC'd) know and
your changes can be built in the side tag too.

(Since there is overlap between the packages that depend on boost and
tbb I'm doing them all at once)
https://fedoraproject.org/wiki/Changes/F40Boost183
https://fedoraproject.org/wiki/Changes/F39TBB2020.3
--
___
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: Should we retire the mailx package?

[Jonathan Wakely]

On Mon, 11 Dec 2023 at 12:03, Jonathan Wakely  wrote:
>
> On Fri, 8 Dec 2023 at 18:47, Adam Williamson  
> wrote:
> >
> > On Fri, 2023-12-08 at 10:38 -0800, Kevin Fenzi wrote:
> > > I'm definitely in favor. I hit this broken step a while back myself. ;(
> > >
> > > Hopefully the current maintainers are on board with this?
> >
> > Yeah, honestly, I'm not sure a Change is the right way to go about
> > this, it seems like it could just be handled between maintainers.
> > nforro - who maintains mailx - has not committed to it for two years,
> > but is very active on other packages (adding him to CC). If he is OK
> > with the change, I would think you could just go ahead and do it (have
> > nforro retire mailx) without needing to go through the Change process.
>
> I CC'd him (and tkorbar) on the first mail in this thread, and I only
> started this thread after emailing them directly to discuss it (I
> probably should have mentioned that I'd already run it by them).
> Nikola suggested in that private discussion that retiring mailx was
> probably the way to go, so I started this thread.
>
> > If you file a Change, I think all that will happen is that a lot more
> > bureaucracy will happen before somebody says "hey, we'd better ask
> > nforro about this" anyway. :D
>
> I think he's already on board with the change, and I think everybody
> would be happier to Just Do It without a change proposal. I just
> wanted to start a discussion and make sure the right process was
> followed.

... and of course to check that nobody would object, on the grounds
that they need the crufty mailx for some reason.

> It sounds like I'm not the only person to waste time scratching my
> head at the heirloom-mailx fossil, and so we should just retire it!
--
___
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: Should we retire the mailx package?

[Jonathan Wakely]

On Fri, 8 Dec 2023 at 18:47, Adam Williamson  wrote:
>
> On Fri, 2023-12-08 at 10:38 -0800, Kevin Fenzi wrote:
> > I'm definitely in favor. I hit this broken step a while back myself. ;(
> >
> > Hopefully the current maintainers are on board with this?
>
> Yeah, honestly, I'm not sure a Change is the right way to go about
> this, it seems like it could just be handled between maintainers.
> nforro - who maintains mailx - has not committed to it for two years,
> but is very active on other packages (adding him to CC). If he is OK
> with the change, I would think you could just go ahead and do it (have
> nforro retire mailx) without needing to go through the Change process.

I CC'd him (and tkorbar) on the first mail in this thread, and I only
started this thread after emailing them directly to discuss it (I
probably should have mentioned that I'd already run it by them).
Nikola suggested in that private discussion that retiring mailx was
probably the way to go, so I started this thread.

> If you file a Change, I think all that will happen is that a lot more
> bureaucracy will happen before somebody says "hey, we'd better ask
> nforro about this" anyway. :D

I think he's already on board with the change, and I think everybody
would be happier to Just Do It without a change proposal. I just
wanted to start a discussion and make sure the right process was
followed.

It sounds like I'm not the only person to waste time scratching my
head at the heirloom-mailx fossil, and so we should just retire it!
--
___
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

Should we retire the mailx package?

[Jonathan Wakely]

Today I learned (the hard way) that Fedora's mailx package (aka
Heirloom mailx) is ancient and buggy. Upstream has been dead for over
a decade and features documented in its man page don't work. The good
news is that Fedora (and RHEL and CentOS) already have s-nail, which
was forked from it ages ago and is still actively developed. They both
provide the POSIX mailx command, configurable via
/etc/alternatives/mailx, and support almost the same options/config
etc.

But 'dnf install mailx' gives you the bad version, and 'dnf search
mailx' doesn't show s-nail at all. So unless you happen to know s-nail
exists, or spend a while googling to see if Heirloom mailx is still
maintained, you'll never learn about the good one.

Is there any reason to keep both packages, when one is old and buggy
and the other is an improved version of the same thing?

Can we retire the mailx package, and then update s-nail with:

Provides: mailx = %{version}-%{release}

(this would work fine because mailx is at 12.5 and s-nail forked from
that and is now at 14.9, so upgrading would be straightforward)

Should I submit a self-contained change proposal to do this?
--
___
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: Making -Wmissing-include-dirs an error?

[Jonathan Wakely]

On Tue, 10 Oct 2023 at 12:17, Ian McInerney via devel
 wrote:
>
>
>
> On Tue, Oct 10, 2023 at 11:59 AM Neal Gompa  wrote:
>>
>> Hey all,
>>
>> Recently, one of the folks working on packaging stuff in Fedora KDE
>> nearly missed an issue caused by GCC emitting a warning about missing
>> include dirs:
>>
>> > cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or directory 
>> > [-Wmissing-include-dirs]
>> > cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or 
>> > directory [-Wmissing-include-dirs]
>>
>> I did manage to figure out this meant we needed an additional build
>> dependency (qt6-qtbase-private-devel, FYI), but it made me think if
>> there's a reason this shouldn't be an error.
>>
>> If it's an error, then at least we can evaluate these things and
>> ensure we have the right build inputs...
>
>
> Missing an include directory isn't necessarily the problem though, it is the 
> missing headers that aren't present when they are included that would be - 
> and that should trigger a build error for the missing file. What advantage 
> does failing on this warning provide that the failure on the include file 
> missing doesn't?

Typically, yes, I'd expect a failure. But it's possible for code to do:

#if __has_include()
# include 
// use features in that header
#else
// roll your own inferior version
#endif

And so the code could compile either way, but with results that differ
depending on whether  is found or not. The extra -I include dir
could be given to the compiler so that if  is present in that
dir, it will be found and used. If it's not present, there's no harm.
I don't expect this to be a very widely used pattern though.

The above doesn't necessarily argue for or against making it an error.
There are arguments either way. Making it an error might give some
maintainers a heads up that something's missing, but for other
packages it would break a valid use case.
___
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: Does a change approved for f39 need reapproval for f40?

[Jonathan Wakely]

On Tue, 31 Oct 2023 at 14:26, Aoife Moloney  wrote:

> Hi Jonathan,
>
> Sorry this (among other things Im sure) fell through the cracks while we
> were without a Fedora Program Manager :(
>

Yep, completely understandable. It wouldn't have been a problem if I had
started the work sooner!


> I will re-announce this on discourse as this is how the process for a
> change targeting F40 goes, and open a new ticket to FESCo after about a
> week or so, and thank you for cleaning up the wiki, it makes it much easier
> to see the discussion surrounding the change from its initial proposal for
> F39 by separating it out in the Current Status section. I'll remove the
> discussion links, tracker bug and fesco ticket for the F40 section and
> re-add with F40 links.
>

Great, thanks.


>
>
> Kindest regards,
> Aoife
>
> On Mon, Oct 30, 2023 at 3:16 PM Neal Gompa  wrote:
>
>> On Mon, Oct 30, 2023 at 10:55 AM Jonathan Wakely 
>> wrote:
>> >
>> > On Mon, 30 Oct 2023 at 14:24, Ian McInerney via devel
>> >  wrote:
>> > >
>> > >
>> > >
>> > > On Mon, Oct 30, 2023 at 2:06 PM Jonathan Wakely 
>> wrote:
>> > >>
>> > >> Well it looks like I took too long to do the deferral to F40, and so
>> > >> FESCO dropped the change:
>> > >> https://pagure.io/fesco/issue/3059#comment-875144
>> > >>
>> > >> So now do I need to re-submit as a fresh change for F40?
>> > >
>> > >
>> > > My reading of the email replies to the FESCO minutes when they
>> announced this (
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/E3M624WQFJV4L5NCJBA3UC746Z7BWNO5/#TMIPXR25CJR72BUMXHKTVICUKVUU5REM)
>> is that they want an entirely new change proposal for it... since they
>> apparently didn't think anyone was working on it and that it was completely
>> abandoned even though you had emailed that you were working on it.
>> >
>> > Drat. I finally have some time to pick up the work on it (having
>> > inherited the change from trodgers after he left) and now I can't do
>> > it! That's kinda annoying, as I had mailed the list about it. I
>> > probably should have updated the change to make myself the owner.
>> >
>> > Fingers crossed I'll still be able to make time for it after it gets
>> > re-approved. I'll submit a new change.
>>
>> If it's substantially the same, just update the wiki page and ask
>> Aoife to create the FESCo ticket so we can approve it again.
>>
>>
>>
>>
>> --
>> 真実はいつも一つ！/ Always, there's only one truth!
>>
>>
>
> --
>
> Aoife Moloney
>
> Fedora Operations Architect
>
> Fedora Project
>
> Matrix: @amoloney:fedora.im
>
> IRC: amoloney
>
>
> ___
> 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: Summary/Minutes from today's FESCo Meeting (2023-09-21)

[Jonathan Wakely]

> On Fri, Sep 22, 2023 at 02:21:38PM +0200, Fabio Valentini wrote:
> 
> Yes, exactly. We have no idea if this will be picked up again (either by
> trodgers or by somebody else), so it seems better to drop it than to pretend
> that we expect it to happen for F40.

Well I had said publicly I was working on it:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/ZK47JMBBBMWCGGSSK2YBILQSQFCL6UTE/

I've resubmitted it for f40 now.
___
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: Does a change approved for f39 need reapproval for f40?

[Jonathan Wakely]

On Mon, 30 Oct 2023 at 14:24, Ian McInerney via devel
 wrote:
>
>
>
> On Mon, Oct 30, 2023 at 2:06 PM Jonathan Wakely  wrote:
>>
>> Well it looks like I took too long to do the deferral to F40, and so
>> FESCO dropped the change:
>> https://pagure.io/fesco/issue/3059#comment-875144
>>
>> So now do I need to re-submit as a fresh change for F40?
>
>
> My reading of the email replies to the FESCO minutes when they announced this 
> (https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/E3M624WQFJV4L5NCJBA3UC746Z7BWNO5/#TMIPXR25CJR72BUMXHKTVICUKVUU5REM)
>  is that they want an entirely new change proposal for it... since they 
> apparently didn't think anyone was working on it and that it was completely 
> abandoned even though you had emailed that you were working on it.

Drat. I finally have some time to pick up the work on it (having
inherited the change from trodgers after he left) and now I can't do
it! That's kinda annoying, as I had mailed the list about it. I
probably should have updated the change to make myself the owner.

Fingers crossed I'll still be able to make time for it after it gets
re-approved. I'll submit a new change.
___
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: Does a change approved for f39 need reapproval for f40?

[Jonathan Wakely]

Well it looks like I took too long to do the deferral to F40, and so
FESCO dropped the change:
https://pagure.io/fesco/issue/3059#comment-875144

So now do I need to re-submit as a fresh change for F40?

On Fri, 11 Aug 2023 at 20:49, Fabio Valentini  wrote:
>
> On Fri, Aug 11, 2023 at 9:43 PM Ben Cotton  wrote:
> >
> > On Fri, Aug 11, 2023 at 2:56 PM Jonathan Wakely  wrote:
> > >
> > > This change got approved  for f39 but couldn't be done in time:
> > > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB
> > >
> > > Does it need to be re-proposed and approved for f40, or can we just do it 
> > > now? (in a side tag, as planned, of course).
> >
> > No, just do it:
> >
> > > Changes that cannot be completed will automatically be deferred to the 
> > > next release and do not require re-submission unless substantial 
> > > revisions are made.
>
> Speaking with my packager and FESCo hats on, I think it would also
> still be OK to push the change to both F40 *and* F39, so there
> wouldn't even be a need to defer at all. If you want to go this route,
> it might be good to ask FESCo for guidance (i.e. file a ticket), but I
> think the likelihood that we'll just tell you "go ahead with the
> changes in both F40 and F39" is pretty high. :)
>
> 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

Does a change approved for f39 need reapproval for f40?

[Jonathan Wakely]

This change got approved  for f39 but couldn't be done in time:
https://fedoraproject.org/wiki/Changes/F39ModernizeTBB

Does it need to be re-proposed and approved for f40, or can we just do it
now? (in a side tag, as planned, of course).
___
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: Modernize Thread Building Blocks for Fedora 39

[Jonathan Wakely]

On Thu, 6 Jul 2023 at 15:15, Jonathan Wakely  wrote:
>
> On Thu, 6 Jul 2023 at 11:46, Jonathan Wakely  wrote:
> >
> > Oops, I meant to CC the package-ow...@fedoraproject.org addresses for
> > the packages I'll be changing (see below).
> >
> > For blender, gazebo, opencascade, and opensubdiv, it's a one line
> > change to the spec file, something like:
> >
> > -BuildRequires:  tbb-devel
> > +BuildRequires:  tbb2020.3-devel
> >
> > If you're happy for me to push that and rebuild the package as
> > provenpackager, let me know and I won't bother you with a pull
> > request.
> >
> > For USD there's a change needed to FindTBB.cmake, so it's slightly
> > more complex (but only slightly).
>
> USD is currently blocked by the python 3.12 update anyway:
>
> DEBUG util.py:442:   Problem 1: conflicting requests
> DEBUG util.py:442:- nothing provides python(abi) = 3.11 needed by
> python3-pyopengl-3.1.6-1.fc38.x86_64 from build
> DEBUG util.py:442:   Problem 2: conflicting requests
> DEBUG util.py:442:- nothing provides python(abi) = 3.11 needed by
> python3-pyside2-1:5.15.7-2.fc38.x86_64 from build
> DEBUG util.py:444:  (try to add '--skip-broken' to skip uninstallable 
> packages)

gazebo is also blocked by the python 3.12 update.

So there are several packages which I need to move to tbb2020.3-devel,
but I can't even do a scratch build to verify that it would build. And
I can't update tbb itself to the new version while packages like
gazebo and blender won't build with the new version.

So I'm doing nothing and hoping that some of the python blockers get
fixed soon enough for me to do the TBB work before the mass rebuild.


>
>
> >
> >
> > On Thu, 6 Jul 2023 at 11:11, Jonathan Wakely  wrote:
> > >
> > > This is a status update for
> > > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB
> > >
> > > The tbb2020.3 compat package has now been added to rawhide:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-15ccd1cedb
> > >
> > > It doesn't include the docs or python modules (you can use the main
> > > tbb package for those).
> > >
> > > The tbb2020.3-devel subpackage conflicts with tbb-devel, as a given
> > > package only needs to build against one or the other, not both.
> > >
> > > Later today I will start submitting pull requests for the packages
> > > which need to switch from BuildRequires: tbb-devel (or similar) to
> > > using tbb2020.3-devel instead. The affected packages are:
> > >
> > > blender
> > > gazebo
> > > opencascade
> > > opensubdiv
> > > usd
> > >
> > > After those packages have been rebuilt against tbb2020.3 I'll create a
> > > side tag and push a new spec file to the 'tbb' package to update it to
> > > version 2021.9.0 (based on the
> > > https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ package made
> > > by Jerry James). Then the remaining packages that depend on tbb can be
> > > rebuilt against the new tbb in the side tag.
___
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: Modernize Thread Building Blocks for Fedora 39

[Jonathan Wakely]

On Thu, 6 Jul 2023 at 11:46, Jonathan Wakely  wrote:
>
> Oops, I meant to CC the package-ow...@fedoraproject.org addresses for
> the packages I'll be changing (see below).
>
> For blender, gazebo, opencascade, and opensubdiv, it's a one line
> change to the spec file, something like:
>
> -BuildRequires:  tbb-devel
> +BuildRequires:  tbb2020.3-devel
>
> If you're happy for me to push that and rebuild the package as
> provenpackager, let me know and I won't bother you with a pull
> request.
>
> For USD there's a change needed to FindTBB.cmake, so it's slightly
> more complex (but only slightly).

USD is currently blocked by the python 3.12 update anyway:

DEBUG util.py:442:   Problem 1: conflicting requests
DEBUG util.py:442:- nothing provides python(abi) = 3.11 needed by
python3-pyopengl-3.1.6-1.fc38.x86_64 from build
DEBUG util.py:442:   Problem 2: conflicting requests
DEBUG util.py:442:- nothing provides python(abi) = 3.11 needed by
python3-pyside2-1:5.15.7-2.fc38.x86_64 from build
DEBUG util.py:444:  (try to add '--skip-broken' to skip uninstallable packages)



>
>
> On Thu, 6 Jul 2023 at 11:11, Jonathan Wakely  wrote:
> >
> > This is a status update for
> > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB
> >
> > The tbb2020.3 compat package has now been added to rawhide:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2023-15ccd1cedb
> >
> > It doesn't include the docs or python modules (you can use the main
> > tbb package for those).
> >
> > The tbb2020.3-devel subpackage conflicts with tbb-devel, as a given
> > package only needs to build against one or the other, not both.
> >
> > Later today I will start submitting pull requests for the packages
> > which need to switch from BuildRequires: tbb-devel (or similar) to
> > using tbb2020.3-devel instead. The affected packages are:
> >
> > blender
> > gazebo
> > opencascade
> > opensubdiv
> > usd
> >
> > After those packages have been rebuilt against tbb2020.3 I'll create a
> > side tag and push a new spec file to the 'tbb' package to update it to
> > version 2021.9.0 (based on the
> > https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ package made
> > by Jerry James). Then the remaining packages that depend on tbb can be
> > rebuilt against the new tbb in the side tag.
___
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: rawhide build errors on i686

[Jonathan Wakely]

On Thu, 6 Jul 2023 at 13:29, Felix Wang  wrote:
>
> I also had the build error of `BuildrootError: could not init mock buildroot, 
> mock exited with status 30`. [1, 2] May I ask how to resubmit the build?

Just repeat exactly the steps you did to submit it the first time.
Probably something like "fedpkg build".

Since there hasn't been a successful build in koji, you can resubmit
the same version of the package and it will happily build it again.
___
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: Modernize Thread Building Blocks for Fedora 39

[Jonathan Wakely]

On Thu, 6 Jul 2023 at 12:43, Richard Shaw  wrote:
>
> On Thu, Jul 6, 2023 at 5:41 AM Jonathan Wakely  wrote:
>>
>> >
>> > Wouldn't it be better to just update OpenCascade to its new upstream 
>> > version in that sidetag as well instead of doing a compat package for it?
>>
>> Define better.
>> To be clear, I'm not "doing a compat package" for it. I'm just
>> changing one line in the spec file and rebuilding it against
>> tbb2020.3-devel (which is currently identical to tbb-devel).
>> That just means the OpenCascade package in rawhide won't be broken
>> when tbb gets updated.
>>
>> > The new OpenCascade actually requires the new TBB and can't be built with 
>> > the older version. See https://bugzilla.redhat.com/show_bug.cgi?id=2217295.
>>
>> Yes, I'm aware of the bugzilla (it's blocked by #2036372 which is this 
>> change).
>
>
> There's no guarantee that the new version won't have new issues and not be a 
> simple update and rebuild. I don't want to hold things up.

Yeah, that's what I figured.

>  For that reason I'm good with the plan as is. Once things have settled in 
> Rawhide I can do test builds of the new version with latest TBB.

OK, thanks for confirming!
___
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: Modernize Thread Building Blocks for Fedora 39

[Jonathan Wakely]

On Thu, 6 Jul 2023 at 11:46, Jonathan Wakely wrote:
>
> Oops, I meant to CC the package-ow...@fedoraproject.org addresses for
> the packages I'll be changing (see below).

Which should be package-matinain...@fedoraproject.org nowadays. Doh.

>
> For blender, gazebo, opencascade, and opensubdiv, it's a one line
> change to the spec file, something like:
>
> -BuildRequires:  tbb-devel
> +BuildRequires:  tbb2020.3-devel
>
> If you're happy for me to push that and rebuild the package as
> provenpackager, let me know and I won't bother you with a pull
> request.
>
> For USD there's a change needed to FindTBB.cmake, so it's slightly
> more complex (but only slightly).
>
>
> On Thu, 6 Jul 2023 at 11:11, Jonathan Wakely  wrote:
> >
> > This is a status update for
> > https://fedoraproject.org/wiki/Changes/F39ModernizeTBB
> >
> > The tbb2020.3 compat package has now been added to rawhide:
> > https://bodhi.fedoraproject.org/updates/FEDORA-2023-15ccd1cedb
> >
> > It doesn't include the docs or python modules (you can use the main
> > tbb package for those).
> >
> > The tbb2020.3-devel subpackage conflicts with tbb-devel, as a given
> > package only needs to build against one or the other, not both.
> >
> > Later today I will start submitting pull requests for the packages
> > which need to switch from BuildRequires: tbb-devel (or similar) to
> > using tbb2020.3-devel instead. The affected packages are:
> >
> > blender
> > gazebo
> > opencascade
> > opensubdiv
> > usd
> >
> > After those packages have been rebuilt against tbb2020.3 I'll create a
> > side tag and push a new spec file to the 'tbb' package to update it to
> > version 2021.9.0 (based on the
> > https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ package made
> > by Jerry James). Then the remaining packages that depend on tbb can be
> > rebuilt against the new tbb in the side tag.
___
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: Modernize Thread Building Blocks for Fedora 39

[Jonathan Wakely]

Oops, I meant to CC the package-ow...@fedoraproject.org addresses for
the packages I'll be changing (see below).

For blender, gazebo, opencascade, and opensubdiv, it's a one line
change to the spec file, something like:

-BuildRequires:  tbb-devel
+BuildRequires:  tbb2020.3-devel

If you're happy for me to push that and rebuild the package as
provenpackager, let me know and I won't bother you with a pull
request.

For USD there's a change needed to FindTBB.cmake, so it's slightly
more complex (but only slightly).


On Thu, 6 Jul 2023 at 11:11, Jonathan Wakely  wrote:
>
> This is a status update for
> https://fedoraproject.org/wiki/Changes/F39ModernizeTBB
>
> The tbb2020.3 compat package has now been added to rawhide:
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-15ccd1cedb
>
> It doesn't include the docs or python modules (you can use the main
> tbb package for those).
>
> The tbb2020.3-devel subpackage conflicts with tbb-devel, as a given
> package only needs to build against one or the other, not both.
>
> Later today I will start submitting pull requests for the packages
> which need to switch from BuildRequires: tbb-devel (or similar) to
> using tbb2020.3-devel instead. The affected packages are:
>
> blender
> gazebo
> opencascade
> opensubdiv
> usd
>
> After those packages have been rebuilt against tbb2020.3 I'll create a
> side tag and push a new spec file to the 'tbb' package to update it to
> version 2021.9.0 (based on the
> https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ package made
> by Jerry James). Then the remaining packages that depend on tbb can be
> rebuilt against the new tbb in the side tag.
___
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: Modernize Thread Building Blocks for Fedora 39

[Jonathan Wakely]

On Thu, 6 Jul 2023 at 11:21, Ian McInerney via devel
 wrote:
>
>
>
> On Thu, Jul 6, 2023 at 11:12 AM Jonathan Wakely  wrote:
>>
>> This is a status update for
>> https://fedoraproject.org/wiki/Changes/F39ModernizeTBB
>>
>> The tbb2020.3 compat package has now been added to rawhide:
>> https://bodhi.fedoraproject.org/updates/FEDORA-2023-15ccd1cedb
>>
>> It doesn't include the docs or python modules (you can use the main
>> tbb package for those).
>>
>> The tbb2020.3-devel subpackage conflicts with tbb-devel, as a given
>> package only needs to build against one or the other, not both.
>>
>> Later today I will start submitting pull requests for the packages
>> which need to switch from BuildRequires: tbb-devel (or similar) to
>> using tbb2020.3-devel instead. The affected packages are:
>>
>> blender
>> gazebo
>> opencascade
>
>
> Wouldn't it be better to just update OpenCascade to its new upstream version 
> in that sidetag as well instead of doing a compat package for it?

Define better.
To be clear, I'm not "doing a compat package" for it. I'm just
changing one line in the spec file and rebuilding it against
tbb2020.3-devel (which is currently identical to tbb-devel).
That just means the OpenCascade package in rawhide won't be broken
when tbb gets updated.

> The new OpenCascade actually requires the new TBB and can't be built with the 
> older version. See https://bugzilla.redhat.com/show_bug.cgi?id=2217295.

Yes, I'm aware of the bugzilla (it's blocked by #2036372 which is this change).

If Richard wants to coordinate and do that update in the side tag,
that would be fine. But it's not a requirement. Switching OpenCascade
to use tbb2020.3 is a one line change to the spec file and that change
can easily be reverted to use tbb again when updating it. Doing it
that way means the tbb update isn't dependent on finishing the
OpenCascade update. That update could be done at any time after tbb
has been updated in rawhide. Or it could *still* be done in the side
tag even if it's already been switched to use tbb2020.3 in rawhide.

Richard, if you do want to do the OpenCascade in the side tag, please
let me know. Otherwise I'll make the minimal change to avoid
OpenCascade having broken deps, and then you can update it at your
leisure once the new tbb lands in rawhide.
___
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

Modernize Thread Building Blocks for Fedora 39

[Jonathan Wakely]

This is a status update for
https://fedoraproject.org/wiki/Changes/F39ModernizeTBB

The tbb2020.3 compat package has now been added to rawhide:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-15ccd1cedb

It doesn't include the docs or python modules (you can use the main
tbb package for those).

The tbb2020.3-devel subpackage conflicts with tbb-devel, as a given
package only needs to build against one or the other, not both.

Later today I will start submitting pull requests for the packages
which need to switch from BuildRequires: tbb-devel (or similar) to
using tbb2020.3-devel instead. The affected packages are:

blender
gazebo
opencascade
opensubdiv
usd

After those packages have been rebuilt against tbb2020.3 I'll create a
side tag and push a new spec file to the 'tbb' package to update it to
version 2021.9.0 (based on the
https://copr.fedorainfracloud.org/coprs/jjames/TBB2021/ package made
by Jerry James). Then the remaining packages that depend on tbb can be
rebuilt against the new tbb in the side tag.
___
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: Red Hat & Fedora -- largely stepping out of this ecosystem

[Jonathan Wakely]

On Sat, 1 Jul 2023 at 20:34, Piotr Szubiakowski wrote:
> I think we all have a problem understanding what this announcement
> means. I do believe CentOS Stream is awesome software. It has to be
> since it's close to what RHEL is. My problem with CentOS Stream is that
> it's not a distribution of my choice, and I feel forced to use CentOS
> Stream. While at the same time, distributions of my choice Fedora,
> Scientific Linux, CentOS Linux, Rocky Linux, and AlmaLinux, are
> consequently taken down, to a moment that I'm not sure whenever RHEL is
> still an open-source software.

I don't know why you're mentioning Fedora here.

Fedora is upstream from RHEL, not downstream. Fedora will not be
"consequently taken down" by this announcement or anything like it.
___
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: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Jonathan Wakely]

On Fri, 30 Jun 2023 at 16:38, Ian Pilcher wrote:
> Rather than expecting runtimes and applications to be fixed to work
> without any timezone information, perhaps the best way forward would be
> to create a tzdata-utc (and similar Java and Python packages).
>
> (Sorry if this has already been suggested & rejected.  I don't remember
> seeing it in this thread, but ...)

From the change proposal:

== Feedback ==
In June of 2021, we proposed creating a new tzdata sub-package that
would only provide the UTC timezone.  As part of the discussion around
this proposal, it was recommended that we completely remove tzdata. We
appreciated this input and welcome additional feedback.
___
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: F39 Change Proposal: Allow Removal of tzdata (System-Wide)

[Jonathan Wakely]

On Mon, 26 Jun 2023 at 19:10, Miro Hrončok  wrote:
>
> Hello Patsy,
>
> On 26. 06. 23 17:54, Aoife Moloney wrote:
> > https://fedoraproject.org/wiki/Changes/AllowRemovalOfTzdata
> >
> > == Summary ==
> > Allow the removal of tzdata especially on containers in order to minimize 
> > size.
> > ...
> >
> > In order for this to work, we need packages that use tzdata at run
> > time to switch from Require'ing tzdata to Recommend'ing tzdata.  These
> > packages should also gracefully handle instances where tzdata has been
> > removed.  For example, this would require recognizing that tzdata is
> > not present and providing an appropriate error, such as recommending
> > that the user install tzdata.
> > ...
> > * python3.XX (3.9, 3.10, 3.11, 3.12)
>
> Who is expected to work on this? Python maintainers or this Change proposal 
> owners?
>
> *PEP 615 – Support for the IANA Time Zone Database in the Standard Library* 
> says:
>
>
> """
> Python distributors are encouraged to ensure that time zone data is installed
> alongside Python whenever possible (e.g. by declaring tzdata as a dependency
> for the python package).
> """
>
> from https://peps.python.org/pep-0615/#system-time-zone-information
>
>
> By changing the Requires to Recommends, we would diverge from upstream
> recommendation.
>
> ---
>
> The current problem with Python without tzdata is:
>
> ===
>  >>> from zoneinfo import ZoneInfo
>  >>> ZoneInfo("Europe/Prague")
> Traceback (most recent call last):
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 12, in load_tzdata
>  return resources.files(package_name).joinpath(resource_name).open("rb")
> ^
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 22, in 
> files
>  return from_package(get_package(package))
>  
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 53, in
> get_package
>  resolved = resolve(package)
> 
>File "/usr/lib64/python3.11/importlib/resources/_common.py", line 44, in 
> resolve
>  return cand if isinstance(cand, types.ModuleType) else
> importlib.import_module(cand)
>
> ^
>File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in 
> import_module
>  return _bootstrap._gcd_import(name[level:], package, level)
> 
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1126, in _find_and_load_unlocked
>File "", line 241, in 
> _call_with_frames_removed
>File "", line 1204, in _gcd_import
>File "", line 1176, in _find_and_load
>File "", line 1140, in _find_and_load_unlocked
> ModuleNotFoundError: No module named 'tzdata'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "", line 1, in 
>File "/usr/lib64/python3.11/zoneinfo/_common.py", line 24, in load_tzdata
>  raise ZoneInfoNotFoundError(f"No time zone found with key {key}")
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key 
> Europe/Prague'

This error looks very similar to the one for a non-existent timezone,
e.g. if I have tzdata installed and create ZoneInfo("Fake/McFakeface")
then I get exactly the same error except for the string
"Europe/Prague" in the last line. So it seems like it's actually
working fine. With no tzdata installed, all time zones are treated as
unknown, with the same result as requesting a completely bogus time
zone.



> ===
>
> Not that ZoneInfo("UTC") also fails:
>
> ===
>  >>> ZoneInfo("UTC")
> Traceback (most recent call last):
> ...
> zoneinfo._common.ZoneInfoNotFoundError: 'No time zone found with key UTC'
> ===
>
> So we would need to patch Python to detect missing tzdata and report something
> like:
>
>   ZoneInfoNotInstalledError: 'No time zone information installed on the 
> system,
> you can only use UTC'

I'm not sure that's really needed. You can just treat missing tzdata
as the extreme case of an unknown time zone, where they're all
unknown.

>
> We would also need to ensure UTC work even without tzdata installed.

Yes, that would be useful.

Although IMHO even that seems like a nice-to-have not an absolute
showstopper. Most containerized workloads that don't need time zone
info probably aren't using ZoneInfo("UTC") to convert from UTC to UTC,
they're probably not using ZoneInfo at all.

>
> I 

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

[Jonathan Wakely]

On Fri, 16 Jun 2023 at 07:50, Miro Hrončok  wrote:
>
> On 13. 06. 23 14:02, Tomas Hrnciar wrote:
> > Hello,
> >
> > in order to deliver Python 3.12, we are running a coordinated rebuild in a 
> > side
> > tag.
> >
> > https://fedoraproject.org/wiki/Changes/Python3.12
> > 
> >
> > We anticipate starting this rebuildsometimethis week.
> >
> > If you see a "Rebuilt for Python 3.12" (or similar) commit in your package,
> > please don't rebuild it in regular rawhideor another rawhide side tag. If 
> > you
> > need to, please let us know, so we can coordinate.
> >
> > If you'd like to build apackageafter we already rebuilt it, you should be 
> > able
> > to build it in the side tag via:
> >
> > on branch rawhide:
> > $ fedpkg build --target=f39-python
> > $ koji wait-repo f39-python --build 
> >
> > Note that it will take a while before all the essential packages are 
> > rebuilt,
> > so don't expect all your dependencies to be available right away. Please, 
> > don't
> > attempt to build your package in the side tag before we do.
> > When in trouble, ask here or on IRC (#fedora-python on Libera.Chat). Ping me
> > (thrnciar) or Miro (mhroncok) if you need to talk to us.
> >
> > Builds:
> > https://koji.fedoraproject.org/koji/builds?latest=0=f39-python=-build_id=0
> >  
> > 
> >
> > Please avoid any potentially disturbing or major changes in Python packages
> > until the rebuild is over.
> >
> > Thanks. Let us know if you have any questions.
>
> The following packages were built in rawhide after they were built in out
> Python 3.12 side tag (f39-python):
>
> codespell
> devscripts
> iscsi-initiator-utils
> libxc
> miniupnpc
> petsc
> python-apypie
> python-bitarray
> python-boto3
> python-cerberus
> python-cloudflare
> python-hpack
> python-pyudev
>
> Please, don't do that.
>
> I will now rebuild them in the side tag again.

And then I went and did a rawhide build for tbb, requiring another
build in the side tag. Sorry about that, for some reason I thought
this tag had merged already :-(
___
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: SPDX Statistics - stilus annunciationis edition

[Jonathan Wakely]

On Monday, March 27, 2023, Andreas Schneider  wrote:
> On Sunday, 26 March 2023 01:56:32 CEST Miroslav Suchý wrote:
>> Two weeks ago we had:
>> > * 23107 spec files in Fedora
>> >
>> > * 29503license tags in all spec files
>> >
>> > * 20302 tags have not been converted to SPDX yet
>> >
>> > * 8096 tags can be trivially converted using `license-fedora2spdx`
>>
>> Today we have:
>>
>> * 22882 spec files in Fedora
>>
>> * 29366license tags in all spec files
>>
>> * 19784 tags have not been converted to SPDX yet(huray, we are under 20k)
>>
>> * 7912tags can be trivially converted using `license-fedora2spdx`
>>
>> The list of packages needed to be converted is again here:
>>
>>
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-fi
>> nal.txt
>>
>> List by package maintainers is here
>>
>>
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-fi
>> nal-maintainers.txt
>
> Looking into this it lists for example:
>
> libtermkey   asn salimma
>
>
> The spec file of libtermkey has:
>
>   License:MIT
>
>
> Now going to https://spdx.org/licenses/ and looking for the SPDX
Identifier
> shows:
>
> MIT License MIT
>
>
> What am I supposed to do as a maintainer of libtermkey?

Double check which kind of MIT the package uses, and ensure it's the right
SPDX identifier.

https://docs.fedoraproject.org/en-US/legal/update-existing-packages/#_mit
___
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 problem: Builds in container, not on machine

[Jonathan Wakely]

On Mon, 20 Mar 2023 at 14:10, Ron Olson wrote:

> Hey all-
>
> I got this issue in my GH account I use for building Swift for Fedora:
> https://github.com/tachoknight/swift-lang-packaging-fedora/issues/2. The
> TL;DR is that the person was trying to build Swift on Rawhide which he
> moved to from an older version of Fedora. This tracks with something I
> discovered as well: I have a current Fedora VM (not Rawhide) that I’ve been
> upgrading from version to version for several years now, and suddenly it
> cannot build Swift due to a series of bizarre error messages like:
>
> …
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/set:60:10:
> note: in file included from
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/set:60:
> #include 
> ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_tree.h:2008:5:
> error: missing '#include
> "gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h"';
> 'pair' must be declared before it is used
> pair ^
> /usr/lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_pair.h:185:12:
> note: declaration here is not visible
> struct pair
> …
>
> However, using mock or a container, it builds fine, Rawhide, F37, whatever.
>
> I’m guessing there’s a setting or environment variable or … ?
>

No, I don't think so. There's no environment variable that is needed to
stop the C++ standard library headers being completely broken.

The errors above and in the GH issue make no sense to me, maybe it's a bug
in Clang's modules that allow a header to be reincluded, but I don't know
why it only shows up on your VM and the reporter's system.
___
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: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

[Jonathan Wakely]

On Thu, 16 Mar 2023 at 00:34, Ben Beasley wrote:

> Thank you for helping dig into the details. What you’ve written makes
> sense, and is consistent with the comments in absl/base/options.h regarding
> ABSL_OPTION_USE_STD_STRING_VIEW:
>
> A value of 2 means to detect the C++ version being used to compile
> Abseil,
> and use an alias only if a working std::string_view is available.  This
> option is useful when you are building your program from source.  It
> should
> not be used otherwise -- for example, if you are distributing Abseil
> in a
> binary package manager -- since in mode 2, absl::string_view will name
> a
> different type, with a different mangled name and binary layout,
> depending on
> the compiler flags passed by the end user.  For more info, see
> https://abseil.io/about/design/dropin-types.
>
>
> https://github.com/abseil/abseil-cpp/blob/c8a2f92586fe9b4e1aff049108f5db8064924d8e/absl/base/options.h#L138
> For completeness, the reason the value of ABSL_OPTION_USE_STD_STRING_VIEW
> changed from 2 to 1 since the previous release is an intentional upstream
> change described as follows:
>
> Change `absl/base/options.h` at install time to reflect the ABI used
> to compile the libraries, i.e., if Abseil was compiled with
> C++ >= 17 then the `ABSL_OPTION_USE_STD_*` macros are set to `1`,
> because then the C++ 17 types are embedded in the ABI of the installed
> artifacts.
>
> Likewise, set the `target_compile_features()` of Abseil libraries
> to reflect the C++ version used to compile them. If they the Abseil
> libraries are compiled with C++ >= 17, then all downstream
> dependencies must also be compiled with C++ >= 17.
>
>
> https://github.com/abseil/abseil-cpp/commit/308bbf300fe9332130f4784c7a91fa2ad707d6e4
>
> So the only way that dependent packages can use C++14 is if we
> intentionally and explicitly downgrade the C++ standard used to compile
> abseil-cpp from C++17 (the default) to C++14.
>
> Given all this, it appears to me that the best course is still to keep
> abseil-cpp on the default C++17 standard and accept that dependent packages
> cannot use C++14. However, I’m pleased to have a much better understanding
> of what is happening, how, and why, and I’m still happy to consider any
> proposals to proceed differently.
>

Agreed. We know why it's needed now, and so can explain it to any
maintainers of packages that need to move to C++17. Thanks for humouring my
curiosity about it!



> On 3/15/23 6:29 PM, Jonathan Wakely wrote:
>
>
>
> On Wed, 15 Mar 2023 at 22:17, Jonathan Wakely  wrote:
>
>>
>>
>> On Wed, 15 Mar 2023 at 22:14, Ben Beasley 
>> wrote:
>>
>>> Thank you for prompting me to look at this more closely. A quick
>>> investigation reveals:
>>>
>>> “Abseil libraries require C++14 as the current minimum standard. When
>>> compiled with C++17 (either because it is the compiler's default or
>>> explicitly requested), then Abseil requires C++17.”
>>>
>>>
>>> https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291
>>>
>>> The abseil-cpp package in Fedora has been compiled as C++17 for some
>>> time—at first explicitly, but this would also now be the default if the
>>> spec file did not configure a particular standard—so it seems dependent
>>> packages already technically needed C++17, and it is mere happenstance that
>>> this particular release is revealing incompatibilities.
>>>
>>
>> I'm not sure if that's true, see my other email which crossed with yours.
>> In the previous release absl::string_view would work for both C++14 and
>> C++17, because USE_STD_STRING_VIEW was defined to 2, so adapted to the
>> headers that included it.
>>
>> In the new release it is hardcoded to only work for C++17. That seems
>> like a new change in the new version, not something that was already
>> present.
>>
>
> Digging deeper, maybe it was true, and ilbc was just getting away with it
> by chance.
>
> Several member functions of absl::string_view are defined out-of-line in
> abseil-cpp-20220623.1/absl/strings/string_view.cc but if the library is
> built as C++17 then those won't be defined (because absl::string_view is
> just an alias for std::string_view, so all the members come from
> libstdc++). So all clients of abseil-cpp shared libs do need to be compiled
> as C++17 or later. It looks like libilbc.so.3.0.4 doesn't actually use any
> libasbl_*.so libs, so only uses libabsl headers, and that's why it "worked"
> when the header was adaptive w.r.t. the string-

Re: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

[Jonathan Wakely]

On Wed, 15 Mar 2023 at 22:17, Jonathan Wakely  wrote:

>
>
> On Wed, 15 Mar 2023 at 22:14, Ben Beasley  wrote:
>
>> Thank you for prompting me to look at this more closely. A quick
>> investigation reveals:
>>
>> “Abseil libraries require C++14 as the current minimum standard. When
>> compiled with C++17 (either because it is the compiler's default or
>> explicitly requested), then Abseil requires C++17.”
>>
>>
>> https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291
>>
>> The abseil-cpp package in Fedora has been compiled as C++17 for some
>> time—at first explicitly, but this would also now be the default if the
>> spec file did not configure a particular standard—so it seems dependent
>> packages already technically needed C++17, and it is mere happenstance that
>> this particular release is revealing incompatibilities.
>>
>
> I'm not sure if that's true, see my other email which crossed with yours.
> In the previous release absl::string_view would work for both C++14 and
> C++17, because USE_STD_STRING_VIEW was defined to 2, so adapted to the
> headers that included it.
>
> In the new release it is hardcoded to only work for C++17. That seems like
> a new change in the new version, not something that was already present.
>

Digging deeper, maybe it was true, and ilbc was just getting away with it
by chance.

Several member functions of absl::string_view are defined out-of-line in
abseil-cpp-20220623.1/absl/strings/string_view.cc but if the library is
built as C++17 then those won't be defined (because absl::string_view is
just an alias for std::string_view, so all the members come from
libstdc++). So all clients of abseil-cpp shared libs do need to be compiled
as C++17 or later. It looks like libilbc.so.3.0.4 doesn't actually use any
libasbl_*.so libs, so only uses libabsl headers, and that's why it "worked"
when the header was adaptive w.r.t. the string-view definition. It doesn't
care that there are no definitions for those string_view member functions,
because it happens to not use those specific member functions.
___
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: Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

[Jonathan Wakely]

On Wed, 15 Mar 2023 at 22:14, Ben Beasley  wrote:

> Thank you for prompting me to look at this more closely. A quick
> investigation reveals:
>
> “Abseil libraries require C++14 as the current minimum standard. When
> compiled with C++17 (either because it is the compiler's default or
> explicitly requested), then Abseil requires C++17.”
>
>
> https://github.com/abseil/abseil-cpp/blob/20230125.1/CMake/AbseilHelpers.cmake#L291
>
> The abseil-cpp package in Fedora has been compiled as C++17 for some
> time—at first explicitly, but this would also now be the default if the
> spec file did not configure a particular standard—so it seems dependent
> packages already technically needed C++17, and it is mere happenstance that
> this particular release is revealing incompatibilities.
>

I'm not sure if that's true, see my other email which crossed with yours.
In the previous release absl::string_view would work for both C++14 and
C++17, because USE_STD_STRING_VIEW was defined to 2, so adapted to the
headers that included it.

In the new release it is hardcoded to only work for C++17. That seems like
a new change in the new version, not something that was already present.
___
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

Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

[Jonathan Wakely]

On Wednesday, March 15, 2023, Jonathan Wakely  wrote:
>
>
> On Wednesday, March 15, 2023, Ben Beasley  wrote:
>> In one week (2023-03-22), or slightly later, I plan to update
abseil-cpp[1] in Rawhide/F39 to the latest LTS release, which is currently
20230125.1. Release notes are available[2].
>>
>> The most significant breaking change is that dependent packages are
required to compile with C++14 or later, and I have found that users of
absl::string_view need C++17 or later.
>
> Hmm, that seems odd. The release notes say C++14 is required but don't
mention that C++17 is needed for some components.
>
> C++17 provides std::string_view so what's the point in using
absl::string_view at all if it only works when std::string_view is already
available?
>
>> This has already been adjusted in a couple of packages (thanks!) and I
have one PR still open[3].
>
>
> The error you showed there says the problem is using std::string_view,
which does indeed require C++17. That doesn't seem related to
absl::string_view, unless there's a bug in abseil which causes
absl::string_view to incorrectly use std::string_view in C++14 mode.
>
> I think something doesn't make sense here, and would beworth
understanding.

OK, abseil has a macro that says whether to define its own string_view or
use the std one:
https://github.com/abseil/abseil-cpp/blob/92ac33b99eb9735a23a5e10150a85ad9d4820065/absl/base/options.h#L127
As you can see in the source code there, the default value is 2, meaning
"use std::string_view if available, but fallback to absl's own string_view
otherwise" (see the comment for more explanation).

In rawhide today, /usr/include/absl/base/options.h has the default value:
#define ABSL_OPTION_USE_STD_STRING_VIEW 2

But in your new abseil-cpp-devel-20230125.1-1.fc39 package it has a
different value:
#define ABSL_OPTION_USE_STD_STRING_VIEW 1

This means that absl::string_view is hardcoded to be an alias for
std::string_view, which means it requires C++17. See lines 135 and 136 at
the link above:
// A value of 1 means to use an alias to std::string_view. This requires
that
// all code using Abseil is built in C++17 mode or later.

This means your new abseil is to blame for the C++17 requirement. For some
reason, your new package hardcodes "the compiler supports C++17" to be
true, which means it cannot be used by any packages that want to build as
C++14. I think your pull request for ilbc is wrong and should not be
merged. Instead you should figure out why abseil-cpp now hardcodes that
macro to 1, and fix that.







>
>
>>
>> All dependent packages build successfully in COPR[4] (with any necessary
C++17 PR’s applied).
>>
>> I will rebuild the following packages in the side tag myself as primary
maintainer or as co-maintainer:
>>
>> - abseil-cpp (of course)
>>
>> - bear
>>
>> - fastnetmon
>>
>> - grpc
>>
>> - libarrow
>>
>> For the remaining packages that need to be rebuilt, when the new version
of abseil-cpp and the rebuilt grpc are ready in the side tag, I will send
an email to their maintainers asking them to rebuild into the side tag.
After a few days, I will ask Rich Mattes, the primary abseil-cpp package
maintainer, to use his provenpackager privileges to rebuild any remaining
dependent packages (and merge the C++17 PR for ilbc if it is still open).
He has already agreed to do so.
>>
>> If you maintain one of the affected packages and you want me to handle
rebuilds in the future, you can grant me privileges on the project;
collaborator on the rawhide branch should be sufficient.
>>
>> - bloaty
>>
>> - credentials-fetcher
>>
>> - fcitx5-mozc
>>
>> - frr
>>
>> - ilbc
>>
>> - libphonenumber
>>
>> - mozc
>>
>> - plasma-dialer
>>
>> - qmlkonsole
>>
>> - spacebar
>>
>> If you maintain one of the affected packages, you should find that you
received this message directly (by BCC due to limitations on the number of
CC recipients imposed by the devel mailing list).
>>
>> [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/10
>>
>> [2] https://github.com/abseil/abseil-cpp/releases/tag/20230125.1
>>
>> [3] https://src.fedoraproject.org/rpms/ilbc/pull-request/1
>>
>> [4] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/
>> ___
>> 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/wik

Heads-up: abseil-cpp 20230125.1 coming to Rawhide/F39

[Jonathan Wakely]

On Wednesday, March 15, 2023, Ben Beasley  wrote:
> In one week (2023-03-22), or slightly later, I plan to update
abseil-cpp[1] in Rawhide/F39 to the latest LTS release, which is currently
20230125.1. Release notes are available[2].
>
> The most significant breaking change is that dependent packages are
required to compile with C++14 or later, and I have found that users of
absl::string_view need C++17 or later.

Hmm, that seems odd. The release notes say C++14 is required but don't
mention that C++17 is needed for some components.

C++17 provides std::string_view so what's the point in using
absl::string_view at all if it only works when std::string_view is already
available?

> This has already been adjusted in a couple of packages (thanks!) and I
have one PR still open[3].


The error you showed there says the problem is using std::string_view,
which does indeed require C++17. That doesn't seem related to
absl::string_view, unless there's a bug in abseil which causes
absl::string_view to incorrectly use std::string_view in C++14 mode.

I think something doesn't make sense here, and would be worth understanding.


>
> All dependent packages build successfully in COPR[4] (with any necessary
C++17 PR’s applied).
>
> I will rebuild the following packages in the side tag myself as primary
maintainer or as co-maintainer:
>
> - abseil-cpp (of course)
>
> - bear
>
> - fastnetmon
>
> - grpc
>
> - libarrow
>
> For the remaining packages that need to be rebuilt, when the new version
of abseil-cpp and the rebuilt grpc are ready in the side tag, I will send
an email to their maintainers asking them to rebuild into the side tag.
After a few days, I will ask Rich Mattes, the primary abseil-cpp package
maintainer, to use his provenpackager privileges to rebuild any remaining
dependent packages (and merge the C++17 PR for ilbc if it is still open).
He has already agreed to do so.
>
> If you maintain one of the affected packages and you want me to handle
rebuilds in the future, you can grant me privileges on the project;
collaborator on the rawhide branch should be sufficient.
>
> - bloaty
>
> - credentials-fetcher
>
> - fcitx5-mozc
>
> - frr
>
> - ilbc
>
> - libphonenumber
>
> - mozc
>
> - plasma-dialer
>
> - qmlkonsole
>
> - spacebar
>
> If you maintain one of the affected packages, you should find that you
received this message directly (by BCC due to limitations on the number of
CC recipients imposed by the devel mailing list).
>
> [1] https://src.fedoraproject.org/rpms/abseil-cpp/pull-request/10
>
> [2] https://github.com/abseil/abseil-cpp/releases/tag/20230125.1
>
> [3] https://src.fedoraproject.org/rpms/ilbc/pull-request/1
>
> [4] https://copr.fedorainfracloud.org/coprs/music/abseil-cpp/packages/
> ___
> 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: Update of catch to Catch2 v3

[Jonathan Wakely]

On Fri, 24 Feb 2023 at 08:20, Vitaly Zaitsev via devel
 wrote:
>
> On 24/02/2023 09:06, Benson Muite wrote:
> > No. There are incompatibilities. Maybe it is better to keep the old
> > name, and use Catch2v3 as a new name, so packages can update more easily
> > when they are ready to do so?
>
> Fedora should go forward. Some packages can be patched trivially:
>
> #if (__has_include()

The parentheses are redundant here.

> #include 
> #else
> #include 
> #endif
>
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> 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: Some boost breakage in Fedora Rawhide

[Jonathan Wakely]

On Thu, 23 Feb 2023 at 18:23, Vít Ondruch  wrote:
>
>
> Dne 23. 02. 23 v 12:41 Zbigniew Jędrzejewski-Szmek napsal(a):
> > On Thu, Feb 23, 2023 at 12:28:48PM +0100, Kalev Lember wrote:
> >> On Thu, Feb 23, 2023 at 12:17 PM Zbigniew Jędrzejewski-Szmek <
> >> zbys...@in.waw.pl> wrote:
> >> I think you got something wrong with your repoquery. Perhaps it picked up
> >> older packages from a published rawhide compose that were still linked with
> >> older boost?
> > It seems so. I thought the compose would have already happened.
>
>
> Compose is broken due to Boost:
>
> https://pagure.io/releng/failed-composes/issue/4654

Strictly speaking, it's broken because of libreoffice.
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Jonathan Wakely]

On Wed, 22 Feb 2023 at 20:52, Thomas Rodgers wrote:
>
> The f39-boost side tag builds have finished.
>
> The following packages are new FTBFS likely due to the Boost update -
[...]
> - usd 
> [[https://kojipkgs.fedoraproject.org//work/tasks/5975/97845975/build.log][build.log]]

The correct log for usd is
https://kojipkgs.fedoraproject.org//work/tasks/2081/97882081/build.log
and it shows errors related to hash_value. Probably related to this
item in the Boost 1.81.0 release notes:

Container Hash:

Major update.
The specializations of boost::hash have been removed; it now always
calls hash_value.

https://www.boost.org/users/history/version_1_81_0.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

Re: Some boost breakage in Fedora Rawhide

[Jonathan Wakely]

On Thu, 23 Feb 2023 at 13:03, Richard W.M. Jones wrote:
> Do you know anything about what's happening with Ceph?

No idea, sorry.
___
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: Some boost breakage in Fedora Rawhide

[Jonathan Wakely]

On Thu, 23 Feb 2023 at 11:41, Zbigniew Jędrzejewski-Szmek wrote:
>
> On Thu, Feb 23, 2023 at 12:28:48PM +0100, Kalev Lember wrote:
> > On Thu, Feb 23, 2023 at 12:17 PM Zbigniew Jędrzejewski-Szmek <
> > zbys...@in.waw.pl> wrote:
> > I think you got something wrong with your repoquery. Perhaps it picked up
> > older packages from a published rawhide compose that were still linked with
> > older boost?
>
> It seems so. I thought the compose would have already happened.
> Sorry for the confusion.
>
> This is shorter, but still quite long.
>
> > My list of things needing rebuild is much shorter:
> >
> > $ dnf repoquery --whatrequires 'libboost*.so.1.78.0()(64bit)'
> > --disablerepo='*' --enablerepo=rawhide-koji -s
> > 0ad-0.0.26-7.fc38.src.rpm
> > blender-3.4.1-11.fc39.src.rpm
> > ceph-17.2.5-11.fc39.src.rpm
> > condor-8.8.15-7.fc37.src.rpm
> > credentials-fetcher-1.1.0-3.fc39.src.rpm
> > cryfs-0.11.2-6.fc38.src.rpm
> > dolfin-2019.1.0.post0-37.fc38.src.rpm
> That's my package. I see 'Rebuilt for Boost 1.81' in dist-git, but
> no attempt in koji (?). I'll start a build now.

I see why it got missed, I'll send a fix to Tom for the makefile.
___
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: FTBFS bug filed, build already deleted

[Jonathan Wakely]

On Wed, 22 Feb 2023 at 14:21, Scott Talbert wrote:
>
> On Wed, 22 Feb 2023, Kevin Kofler via devel wrote:
>
> > Julian Sikorski wrote:
> >> FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> >> build [2] has already been deleted. This is not ideal from maintainer
> >> perspective as it effectively is a bug with no info provided whatsoever.
> >> Not to mention being quite wasteful from the resources perspective as
> >> mame builds take quite a while.
> >> While not much can be done now, can we make sure that the mass rebuild
> >> builds do not get garbage collected, or at least the build logs are
> >> saved somewhere? Thanks.
> >
> > This is a constantly recurring problem. I have run into this very
> > frequently. The retention period for failed build logs is way too short. It
> > needs to be at least 13 months (the approximate time we get to fix an FTBFS
> > bug before the package is retired).
>
> I have to agree here.  There is nothing more frustrating as a contributor
> than going to investigate a FTBFS for a package and finding the logs are
> gone.

When it's a hard-to-reproduce issue on s390x, then I agree, it's a
problem when the only info about the failure is gone.

But the current situation is different. The mass rebuild failures are
usually failures on every arch, due to changes in the buildroot
(typically GCC 13, but sometimes other things that changed since the
last successful build of the package). And the failures can be easily
reproduced with a new scratch build, and then you have fresh logs.
It's an inconvenience, sure, but I regularly encounter far more
frustrating things to deal with as a contributor :-)
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Jonathan Wakely]

On Thu, 23 Feb 2023 at 11:10, Miro Hrončok wrote:
>
> On 23. 02. 23 11:50, Jonathan Wakely wrote:
> > On Thu, 23 Feb 2023 at 09:34, Miro Hrončok wrote:
> >>
> >> On 23. 02. 23 2:37, Thomas Rodgers wrote:
> >>> imath is listed as a prerequisite for OpenImageIO, but not openvdb. Fixed 
> >>> now.
> >>
> >> Listed where? It's not necessary to construct a dependency tree, it was
> >> entirely possible to keep restarting the failures until nothing else built 
> >> the
> >> last time I run a Boost rebuild.
> >
> >
> > Yes, it's possible to just keep building, but it's faster and uses
> > fewer resources to build in dependency order. And the process can be
> > left unattended.
> >
> > One or two missing dependencies can easily be dealt with afterwards,
> > rather than dozens of rebuilds being started in a loop until they
> > work.
> >
> > If you want to use brute force for your rebuilds, go ahead, but that's
> > not the only way :-)
>
> Sure, I just wanted to point out that if the dependency tree calculation is
> flawed, using brute force could have prevented this.
>
> I'd take wasting machine resources over wasting people resources any day.

Agreed. The missing dependency info could/should have been spotted and
corrected, and then new builds run, before merging the side tag back
to rawhide.
___
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: Some boost breakage in Fedora Rawhide

[Jonathan Wakely]

On Thu, 23 Feb 2023 at 11:29, Kalev Lember  wrote:
> I think you got something wrong with your repoquery. Perhaps it picked up 
> older packages from a published rawhide compose that were still linked with 
> older boost?
>
> My list of things needing rebuild is much shorter:

This list is what I'd expect to see, and I think all of those either
have an open FTBFS in bugzilla (some failed in the mass rebuild
already, a few are new failures with Boost 1.81) or have been fixed
already (e.g. rstudio).
___
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: Some boost breakage in Fedora Rawhide

[Jonathan Wakely]

On Thu, 23 Feb 2023 at 11:33, Jonathan Wakely  wrote:
>
> On Thu, 23 Feb 2023 at 10:49, Richard W.M. Jones  wrote:
> >
> > boost 1.81.0 (side tag f39-boost) was merged into Fedora earlier this week:
> >
> >   https://koji.fedoraproject.org/koji/packageinfo?packageID=1074
> >
> > These are the builds in the side tag:
> >
> >   
> > https://koji.fedoraproject.org/koji/builds?inherited=0=63053=-build_id=1
> >
> > However I think some packages didn't get rebuilt.  Definitely
> > systemtap, which causes this problem with qemu:
> >
> >   https://koschei.fedoraproject.org/package/qemu?collection=f39
> >
> >   - nothing provides libboost_system.so.1.78.0()(64bit) needed by 
> > systemtap-devel-4.8-2.fc38.x86_64
> >
> > Possibly ceph, causing:
> >
> >   https://koschei.fedoraproject.org/package/virt-v2v?collection=f39
> >   https://koschei.fedoraproject.org/package/libguestfs?collection=f39
> >
> >   - nothing provides libboost_thread.so.1.78.0()(64bit) needed by 
> > librados2-2:17.2.5-11.fc39.x86_64
> >   - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by 
> > librados2-2:17.2.5-11.fc39.x86_64
> >
> > There's a comment in the current ceph package saying that it's
> > incompatible with boost 1.81 so they've switched back to the bundled
> > copy.  However we still don't have an installable package.
> >
> > I think systemtap needs to be added to the list of packages that
> > depend on boost for next time.  The systemtap spec file is a maze of
> > twisty RPM macros all alike, so perhaps whatever script is used to
> > check for things requiring boost got confused:
> >
> >   https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec
>
> systemtap is already in the list (and I bumped the spec file for it
> before Tom started the rebuilds).
>
> It didn't get rebuilt because it depends on dyninst, which is FTBFS
> with GCC 13 due to header changes (I think fche has a fix pending).
>
> Once dyninst has been rebuilt, then systemtap can be rebuilt.

FWIW the list of packages to rebuild for Boost is obtained using this
command, which I ran on Monday just before the rebuilds started:

dnf repoquery -s --releasever=rawhide --whatrequires libboost\*
--repo=fedora | sed -n 's/-[[:digit:]].*//p' | grep -v '^boost$' |
sort -u

If there's something wrong with that, we can change it.
___
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: Some boost breakage in Fedora Rawhide

[Jonathan Wakely]

On Thu, 23 Feb 2023 at 10:49, Richard W.M. Jones  wrote:
>
> boost 1.81.0 (side tag f39-boost) was merged into Fedora earlier this week:
>
>   https://koji.fedoraproject.org/koji/packageinfo?packageID=1074
>
> These are the builds in the side tag:
>
>   
> https://koji.fedoraproject.org/koji/builds?inherited=0=63053=-build_id=1
>
> However I think some packages didn't get rebuilt.  Definitely
> systemtap, which causes this problem with qemu:
>
>   https://koschei.fedoraproject.org/package/qemu?collection=f39
>
>   - nothing provides libboost_system.so.1.78.0()(64bit) needed by 
> systemtap-devel-4.8-2.fc38.x86_64
>
> Possibly ceph, causing:
>
>   https://koschei.fedoraproject.org/package/virt-v2v?collection=f39
>   https://koschei.fedoraproject.org/package/libguestfs?collection=f39
>
>   - nothing provides libboost_thread.so.1.78.0()(64bit) needed by 
> librados2-2:17.2.5-11.fc39.x86_64
>   - nothing provides libboost_iostreams.so.1.78.0()(64bit) needed by 
> librados2-2:17.2.5-11.fc39.x86_64
>
> There's a comment in the current ceph package saying that it's
> incompatible with boost 1.81 so they've switched back to the bundled
> copy.  However we still don't have an installable package.
>
> I think systemtap needs to be added to the list of packages that
> depend on boost for next time.  The systemtap spec file is a maze of
> twisty RPM macros all alike, so perhaps whatever script is used to
> check for things requiring boost got confused:
>
>   https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec

systemtap is already in the list (and I bumped the spec file for it
before Tom started the rebuilds).

It didn't get rebuilt because it depends on dyninst, which is FTBFS
with GCC 13 due to header changes (I think fche has a fix pending).

Once dyninst has been rebuilt, then systemtap can be rebuilt.
___
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

Fwd: fedmsg notification

[Jonathan Wakely]

What does this notification mean, and how do I turn it off?

The filter UI for notifications is impossible to understand.

-- Forwarded message -
From: 
Date: Thu, 23 Feb 2023 at 10:25
Subject: fedmsg notification



Notification time stamped 2023-02-23 10:25:03 UTC


https://bodhi.fedoraproject.org

--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/jwakely.id.fedoraproject.org/email/29140
___
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: [HEADS UP] Fedora 39 Boost 1.81 rebuilds starting Monday 2022-02-20

[Jonathan Wakely]

On Thu, 23 Feb 2023 at 09:34, Miro Hrončok wrote:
>
> On 23. 02. 23 2:37, Thomas Rodgers wrote:
> > imath is listed as a prerequisite for OpenImageIO, but not openvdb. Fixed 
> > now.
>
> Listed where? It's not necessary to construct a dependency tree, it was
> entirely possible to keep restarting the failures until nothing else built the
> last time I run a Boost rebuild.


Yes, it's possible to just keep building, but it's faster and uses
fewer resources to build in dependency order. And the process can be
left unattended.

One or two missing dependencies can easily be dealt with afterwards,
rather than dozens of rebuilds being started in a loop until they
work.

If you want to use brute force for your rebuilds, go ahead, but that's
not the only way :-)
___
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 38 mass rebuild is finished

[Jonathan Wakely]

On Tue, 24 Jan 2023 at 22:53, Gary Buhrmaster  wrote:
>
> 
>
> On Tue, Jan 24, 2023 at 7:29 AM Jeff Law  wrote:
>
> > On 1/24/23 00:16, Jakub Jelinek wrote:
> > > See
> > > https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
> > > Some libstdc++ headers included  in older versions
> > > as an implementation detail but no longer do.
> > >
> > > Including stdint.h will introduce ::uint32_t type among others,
> > > but not std::uint32_t, if you use the latter, you need to
> > > include .
> > I've got a partial list of packages affected by the ongoing header
> > cleanups in libstdc++:
>
> I am in favor of header cleanups, and moving forward
> with new(er) gcc versions, but I wonder that if in the
> future the Fedora gcc change proposal can reference
> the porting changes rather than referring only to the
> main gcc docs as an additional heads up (in this case,
> I skimmed the gcc 13 changes page, but you had to
> follow yet another link for porting issues to see the
> library header changes (and I did not go looking
> there, my bad)).

I think linking to that page would be a good idea. My only reservation
is that a lot of the content of that page gets written *after* we do a
mass rebuild with the new gcc, because that is when we find which
changes cause the biggest porting headaches. When the change proposal
gets written the porting-to page isn't very well populated. But we
could still link to it, even if it's not very useful until closer to
the mass rebuild.

> While it may take me only a minute to recognize
> the issue when I see the compile failure for a
> missing header ("and there they go again..."),
> writing PRs for upstreams and getting those fixes
> into their release cycle may take somewhat longer
> (and I prefer not to carry local patches in packages
> when possible).
>
> Had I seen cstdint I like to think that I would have
> tried a rebuild with gcc 13 earlier to see what
> (if any) upstream(s) needed some encouragement
> for support gcc 13.

Well if it would encourage people to try the new GCC earlier, we
should definitely link to that page in the change proposal :-)
___
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 38 mass rebuild is finished

[Jonathan Wakely]

On Tue, 24 Jan 2023 at 07:29, Jeff Law  wrote:
>
>
>
> On 1/24/23 00:16, Jakub Jelinek wrote:
> > On Tue, Jan 24, 2023 at 10:00:47AM +0300, Vascom wrote:
> >> I have some packages failed.
> >> One of them libtins. Problem is that:
> >>
> >> error: 'uint32_t' is not a member of 'std';
> >>
> >> Is it normal? Is it GCC 13 change?
> >
> > See
> > https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes
> > Some libstdc++ headers included  in older versions
> > as an implementation detail but no longer do.
> >
> > Including stdint.h will introduce ::uint32_t type among others,
> > but not std::uint32_t, if you use the latter, you need to
> > include .
> I've got a partial list of packages affected by the ongoing header
> cleanups in libstdc++:
>
> intel-igc
> j4-dmenu-desktop
> julia
> jd
> jigdo
> mtxclient
> openclonk
> texlive-base
> tcpflow
> synergy
> R-svglite
> rstudio
> rssguard
> rpi-imager
> rocm-opencl
> rocksdb
> qucs
> parzip
> root
> openmsx
> openlierox
> openexr
> openexr2
> openms
> mongo-cxx-driver
> kakoune
>
>
> I'm sure there's more, I've probably looked at about 20% of the packaged
> I'd flagged as needing further analysis.  But that might help folks
> chase these things down.

The header cleanups will continue until morale improves!

The point of these changes is to speed up compilation. Removing
unnecessary headers means the compiler has less work to do, so koji
builds use less time and less power. The fixed package also becomes
more portable and more standard conforming. The  header isn't
expensive to compile, but what changed is actually that 
and  are no longer included in so many places, and those were
transitively including . Not including  where it
isn't needed removes thousands of lines of code. Most code seems to
remember to include  to use std::string, but everybody forgets
to include  for std::int32_t etc.

Looks like these have that issue and need to include :

widelands
warzone2100
uhd
usd
tcpflow
synergy
snapper
safeint
rstudio
rocksdb
rocm-opencl
prusa-slicer
plug
pingus
paraview
openms
openmsx

I didn't look at any packages starting with the letters A-N so there
are probably more.

Similarly, supertuxkart is missing  or .

pdns is missing 

openvdb failed but should work OK now as there's been an updated tbb.
___
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 38 mass rebuild is finished

[Jonathan Wakely]

On Tue, 24 Jan 2023 at 07:01, Vascom  wrote:
>
> I have some packages failed.
> One of them libtins. Problem is that:
>
> error: 'uint32_t' is not a member of 'std';
>
> Is it normal? Is it GCC 13 change?
>
> I must patch sources now?
> sed -i 's|stdint.h|cstdint|' include/tins/ip_address.h

std::uint32_t is defined in . If the sources don't include
that header, that is a bug.

This is the same thing we have mass rebuild: C and C++ code must
include the headers for the features it uses.

If you get an error saying something is not declared, make sure the
right header is included.
___
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: SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?

[Jonathan Wakely]

On Thu, 19 Jan 2023 at 10:52, Michal Schorm  wrote:
>
> Hello,
> While playing around with Sourcegraph, which indexed all Fedora
> package repositories, I was able to craft a query listing all '%if'
> conditionals referencing Fedora releases that reached EOL.
>
> https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%3D%3E%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B012345%5D.*%29+count:all=regexp=yes=0=group
>
> I don't believe such conditions have any value and I think we can
> remove them right away.
> I think the removal shouldn't affect neither Fedora nor derived
> operating systems.
>
> If removed, they will be preserved in the git history anyway, for
> anyone seeking historical code.
>
> In some cases the conditionals hold patches that could be removed with them:
>
> https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraproject%5C.org/rpms+file:.spec+%28%25if.*%25%7B%5C%3Ffedora%7D.*%5B%3C%5D.*%29%28%5B12%5D%5B0-9%5D%7C%5B3%5D%5B0123456%5D.*%5Cn%2B%29%28.*%5Cn%3F%29%28%25patch.*%29+count:all=regexp=yes=0=group
>
> --
>
> Do you agree it would be safe to remove such conditionals and the code
> they hold ?

For the packages I (co)maintain, I see no value in keeping it. Maybe
somebody has a reason for keeping it in their specs, but I can't see
any value in it.

> Do you agree that removing obsolete code such as this brings value to
> the package codebase ?

Yes, it makes it easier for others to open the spec file and quickly
understand what it's doing.

> Would you see a value in e.g. some kind of a robot reminding
> maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI
> check)

I don't think that's worth the effort/noise.
___
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: vtk build failure with gcc 13.0.0 - enum class

[Jonathan Wakely]

On Tue, 17 Jan 2023 at 09:04, Jakub Jelinek wrote:
>
> On Mon, Jan 16, 2023 at 09:36:39PM -0700, Orion Poplawski wrote:
> > elaborated-type-specifier for a scoped enum must not use the 'class' keyword
> >33 | enum class EndiannessType : std::uint8_t
> >   |  ^
>
> The actual bug is shown in later errors.
> > 'int32_t' is not a member of 'std'; did you mean 'int32_t'?
> >   103 |   std::array ComputeExtent() const;
> >   |   ^~~

Yes, unfortunately GCC gives a pretty bad diagnostic when an
undeclared type is used as an enum-base:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758


>
> See https://gcc.gnu.org/gcc-13/porting_to.html , in particular (something
> that is there every year) Header dependency changes:
>
> Some C++ Standard Library headers have been changed to no longer include 
> other headers that were being used internally by the library. As such, C++ 
> programs that used standard library components without including the right 
> headers will no longer compile.
>
> The following headers are used less widely in libstdc++ and may need to be 
> included explicitly when compiling with GCC 13:
>
>  (for std::int8_t, std::int32_t etc.) // This case
>
> So, likely with GCC 12 and older cstdint has been included as implementation
> detail by one of the libstdc++ headers VTK includes but isn't included
> anymore.
>
> Jakub
> ___
> 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: F38 proposal: Shorter Shutdown Timer (System-Wide Change proposal)

[Jonathan Wakely]

On Wed, 11 Jan 2023 at 16:36, Zbigniew Jędrzejewski-Szmek wrote:
>
> On Tue, Jan 10, 2023 at 06:16:07PM -0800, Kevin Fenzi wrote:
> > Ok, but it seems safer to just add timeouts to things that take too long
> > and can safely be killed off rather than lowering the timeout for
> > everything and potentially kill things that cannot safely be killed.
> >
> > I realize it's a lot more work to try and fix particular slow things.
> >
> > It's hard to know what really needs more time and what just should be
> > killed off sooner. :(
>
> We have thousands of systemd services in Fedora. To "just add timeouts
> to things that take too long" would mean updating them individually.
> (Or maybe only some, but we don't really know which ones.)
> This is never going to happen, it's just too much work, and there is
> no clear clear understanding if it is "safe" for any specific service.
>
> Instead, the idea is to attack the problem from the other end: reduce
> the timeout for everyone. Once this happens, we should start getting
> feedback about what services where this doesn't work. Some services
> legitimately need a long timeout (databases, etc), and for those the
> maintainers would usually have a good idea and can extend the timeout
> easily. Some services are just buggy, and with the additional visibility
> and tracebacks, it should be much easier to diagnose why they are slow.
>
> Approaching the problem from this side is much more feasible. We'll
> probably have to touch a dozen files instead of thousands.

But most of those thousands of services never cause delays at
shutdown, so don't need to be touched in either case. The default
doesn't matter for them, as they never timeout anyway. The services
that do cause problems are less common, and only those ones would need
to be given a shorter timeout to solve most of the problems users
experience.

IIUC the difficulty is finding out which ones are being slow, but that
could be solved by changing the signal to SIGABRT, right?
___
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: Schedule for Tuesday's FESCo Meeting (2023-01-03)

[Jonathan Wakely]

On Thu, 5 Jan 2023 at 17:47, Demi Marie Obenour  wrote:
>
> On 1/5/23 11:08, Frank Ch. Eigler wrote:
> >
> >> Of course, but the benefit is to fix performance bugs in applications
> >> or maybe the desktop itself. [...]
> >
> >>> Let's be firm in testing this empirically rather than aspirationally.
> >> I really don't know how. Suggestions welcome.
> >
> > I'd put the onus on the proponents of the Change, who made predictions
> > like "I'm confident that over the course of the next year, we'll recover
> > performance that was lost by FORTIFY_SOURCE=3 and frame pointers" and
> > "The optimizations enabled by profiling can be much larger than 3-10%."
>
> As the one who made this statement: Profiling can result in very large
> gains.  I cannot predict what the actual gains will be.

But they should be measurable, right? If profiling can't actually
measure performance and track improvements in performance, the change
isn't useful. So it should be possible to show the benefits over the
next release or two.

Aside: could the change proposal please be updated to show *how* to
opt out, not just state it can be done trivially?

I shouldn't have to find
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/231#request_diff
to know whether the right opt-out is to %undefine the new macro, or to
define it to 0, or something else.


>
> > There needs to be substance behind such predictions if they are going
> > to be used as justification for slowing things down in the mean time.
>
> I agree.
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> ___
> 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: Schedule for Tuesday's FESCo Meeting (2023-01-03)

[Jonathan Wakely]

On Tue, 3 Jan 2023 at 09:39, Miro Hrončok  wrote:
>
> = New business =
>
> #2923 Re-vote for Change proposal: Add -fno-omit-frame-pointer to default
> compilation flags
> https://pagure.io/fesco/issue/2923

Given the controversial nature of this one, why was it re-litigated at
short notice when a large number of the stakeholders were still on
vacation?
___
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: F40 proposal: Porting Fedora to Modern C (System-Wide Change proposal)

[Jonathan Wakely]

On Wed, 26 Oct 2022 at 13:24, Milan Crha wrote:
> Looking into the db.h file, it has there a comment that it can add the
> `u_int`, when the system doesn't provide it, but that related block is
> empty in Fedora. More interestingly, even when I add `#define
> __USE_MISC 1` at the very top of the program, thus the

Never ever do that. The __USE_xxx macros are internal, for glibc to
use. You should not ever check them or define them.

https://lwn.net/Articles/590381/

There are several public macros that you can use to enable additional
features, like -D_GNU_SOURCE or _D_DEFAULT_SOURCE, so use those not
the __USE_xxx ones.
___
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: Troubleshooting EPEL 8 build

[Jonathan Wakely]

On Fri, 9 Sept 2022 at 13:58, Ron Olson  wrote:
>
> Hey all-
>
> I’m having an issue trying to get Swift 5.6.3 built on EPEL-8, even though it 
> builds fine for everything else (Rawhide, F36, F35, EPEL-9): “undefined 
> reference to 'std::__throw_bad_array_new_length()’”.

That symbol was added in GCC 11.1, so if you're getting an undefined
reference for it, then it means something is linking against the old
libstdc++.so.6 from the system GCC, not the one from gcc-toolset-11.
___
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

Unretire pstreams-devel

[Jonathan Wakely]

I didn't notice that this package got orphaned then retired. I plan to
maintain it (I'm the author of the code, but somebody else added it to
Fedora so I just let them do the maintenance, which never really
needed any work).

I've submitted a ticket to unretire it.
___
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: F37 proposal: RPM Macros for Build Flags (System-Wide Change proposal)

[Jonathan Wakely]

On Fri, 24 Jun 2022 at 09:32, Florian Weimer wrote:
> >>> With these new macros, the examples from above could be re-written as:
> >>>
> >>>  compiler-rt: %global _pkg_extra_cflags -D_DEFAULT_SOURCE
> >>>  julia:   %global _flag_glibcxx_assertions %{nil}
> >> Do you have some background why -D_DEFAULT_SOURCE is needed?  Why
> >> doesn't upstream detect this?
> >>
> >
> > It was added to workaround this bug: 
> > https://sourceware.org/bugzilla/show_bug.cgi?id=25271
>
> This has long since been fixed, so the workaround is no longer needed.
>
> -D_GLIBCXX_ASSERTIONS has zero false positives.  Removing it does not
> make the code that triggers the asserts well-defined.  Only the explicit
> assertion failure is gone.  So it is probably another example of a flag
> where removal does not result in the hoped-for change in toolchain
> behavior.

Yes, I don't think an example of how to hide undefined behaviour is a
good example for the change proposal.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: You can't be serious! you want to remove mesa-libGL.i686 support?

[Jonathan Wakely]

On Wed, 13 Jul 2022 at 11:04, Jiri Vanek  wrote:
>
> Hi All!
>
> On 7/6/22 01:24, Miro Hrončok wrote:
> > On 06. 07. 22 1:17, Miro Hrončok wrote:
> >> On 06. 07. 22 0:14, Kevin Kofler via devel wrote:
> >>> Stephen Smoogen wrote:
>  Hyperbole aside, it isn't a joke. Looking at the chain we see a common
>
>
> If mesa's i686 support should be removed, then this proposal would need to be 
> reverted.
>
> I had filled bugs against all native direct dependencies of java (eg 
> subversion) and against all packages, which transitively depends on java, and 
> are themsleves important (being dependence of 78+ other  pkgs[that is where 
> the non linear
> curve really started to grow]). All direct no-arch deps got injected 
> ExclusiveArch: %{java_arches}. See 
> https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs#Workflow; there are 
> also exact listings of what was filled bug agasint.
>
>  problem where subversion relies on java-11-openjdk and without it is 
>  going
>  to cause a lot of packages to be removed. Either subversion needs to lose
>  that requirement or a lot of packages are going to get removed as failure
>  to build in i686.
> 
>  libglvnd-glx<-mesa-libGL<-libxcb<-doxygen<-git<-subversion<-java-11-
> >>> openjdk-devel
> 
>  This email isn't a comment about it being a good or bad thing.. it is 
>  just
>  what is being presented.
> >>>
> >>> I do not see why bogus "bug" reports are filed against a bazillion 
> >>> packages
> >>> when subversion is the only package that needs to be fixed.
>
> I cant agree. Of course subversion is main to act, but afaik all its 
> dependence should be warned. Otherwise they would suddenly got very weird  
> FTBFS on i686.

No they won't, because only the subversion-hljava subpackage depends
on java, so packages that have Requires:subversion or BR:subversion
are not affected at all by removing subversion-hljava on i686.


> My investigations shown, probably nothing will be affected by removal of jdk 
> on i686 and the fix in subversion and automake/autotools is fluid and, again, 
> will damage nothing. However I'm not sure. I can not possibly see into all 
> details of
> all affected packages.
> Where casual pkg which is being depndent by nothing, may simply get weird 
> FTBFS, but not a package, on which half of the system depend.
> >>>
> >>> File a bug against subversion, put it on the release blocker tracker, and 
> >>> do
> >>> not waste everyone else's time.
>
> Thus saying, is it really waste of time?  I really doubt. It is making people 
> aware of quite major happening, and thus about fact, that they may be 
> affected, even if they did not know. Maybe "the script that generated this 
> data and filed
> bugs for
> packages affected by the removal of Java packages on i686 was a bit 
> over-zealous." ( to quote :) ) but I still somehow finds it correct.

A HEADS UP email to this list makes people aware. Dozens of bugs that
will be closed without action is not helpful though.

> >>
> >> Jiri, could you please close all the bugzillas that were only opened due 
> >> to the subversion<-java dependency now when 
> >> https://bugzilla.redhat.com/show_bug.cgi?id=2103909 was fixed?
> >
> > I've closed some bugs for very important components manualy, but there are 
> > simply too many.
>
> Argh:( You should have not. I'm really reluctant to do so. How can you proof 
> the package is really not affected by the change?

Because it's obvious from looking at the subversion.spec that the main
'subversion' RPM is not affected in any way by the Java changes.


> I have actually second set of dependent packages (with 50-77 dependencies) 
> prepared to fill bug aganst, if the mass rebuild next week goes bad.
>
> If this thread asks me to close the transitive depndencies of subversion to 
> be closed,  I will do so. But I relly think it is bad idea. Owner should  
> check the impact, and close on his own. And actually it is no tso much. It is 
> less then 50
> which depends *only* on subversion.

But depending on subversion is the wrong check, because subversion
doesn't depend on Java, only subversion-hljava does.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Once again, more than 8 days delayed notifications

[Jonathan Wakely]

On Mon, 11 Jul 2022 at 15:06, Stephen Smoogen wrote:
> That said, IRC is actually one of the fastest ones we can push to.

Is https://apps.fedoraproject.org/notifications/ really still sending
notifications to freenode though?

Hasn't everybody moved to libera?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: You can't be serious! you want to remove mesa-libGL.i686 support?

[Jonathan Wakely]

On Tue, 5 Jul 2022 at 23:15, Kevin Kofler via devel
 wrote:
>
> Stephen Smoogen wrote:
> > Hyperbole aside, it isn't a joke. Looking at the chain we see a common
> > problem where subversion relies on java-11-openjdk and without it is going
> > to cause a lot of packages to be removed. Either subversion needs to lose
> > that requirement or a lot of packages are going to get removed as failure
> > to build in i686.
> >
> > libglvnd-glx<-mesa-libGL<-libxcb<-doxygen<-git<-subversion<-java-11-
> openjdk-devel
> >
> > This email isn't a comment about it being a good or bad thing.. it is just
> > what is being presented.
>
> I do not see why bogus "bug" reports are filed against a bazillion packages
> when subversion is the only package that needs to be fixed.

In fact just one subpackage of subversion, subversion-javahl.

All the packages (like git) that depend on the main subversion package
are completely unaffected if the subversion-javahl subpackage goes
away on i686.

And even for git, only the git-svn.noarch subpackage has
Requires:subversion. The git package does have
BuildRequires:subversion for the tests but again, it's not the
subversion-javahl subpackage, and will be completely unaffected by
updates to remove subversion-javahl on i686.

AFAICT nothing depends on subversion-javahl and so nothing will be
affected by removing it on i686, and so no packages need to care about
the change to subversion that is already in rawhide.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

[Jonathan Wakely]

On Wed, 6 Jul 2022 at 15:57, Jeff Law  wrote:
>
>
>
> On 7/6/2022 8:20 AM, Michael Catanzaro wrote:
> > On Wed, Jul 6 2022 at 08:06:45 AM -0600, Jeff Law
> >  wrote:
> >> If I'm understanding things correctly, the original proposal is trying
> >> to make a very special case of profiling work better -- a case that
> >> 99.9% of Fedora users do not need or care about.That seems like a
> >> particularly bad cost/benefit for this proposal.
> >
> > But all Fedora users benefit from performance improvements implemented
> > as a result of profiling.
> Yes, but, IMHO, you need to find another way to do the profiling you
> need to get those improvements.

Right. Developers already need to rebuild packages locally. The
suggestion that developers of fedora packages can't improve those
packages without making system-wide profiling work on every fedora
users' machines seems like nonsense.

Let's say you profile something and find a performance problem. You
tweak the code to improve performance. How do you verify if it
improves performance? Do you push the change to rawhide, wait for koji
and bodhi to do their thing, then re-profile with the new packages
from the updates-testing repo? And if that didn't work, push another
change to rawhide, wait for koji and bodhi, and re-profile? Of course
not, that would be ridiculous.

You build locally and profile using your locally built packages. So
you're already doing rebuilds, and you're already profiling custom
builds anyway. So you can add frame pointers back in to your local
builds that are used for profiling. It's not essential for frame
pointers to be present in the official koji builds for you to do that.
It might be a minor convenience because it reduces the number of
system libs that you need to rebuild locally, but it's just a
convenience, not a necessity.

Maybe we could make it easier to do local mock builds (or copr builds,
or koji scratch builds) with changes to RPM_OPT_FLAGS to simplify
rebuilding to get frame pointers. But pushing that to every user just
so a handful of people don't have a few extra steps is the wrong
trade-off.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Fedora 37 Boost 1.78 rebuilds starting in a side tag

[Jonathan Wakely]

On Thu, 5 May 2022 at 09:46, Miro Hrončok  wrote:
>
> On 04. 05. 22 1:34, Thomas Rodgers wrote:
> > We are starting the rebuilds for
> > https://fedoraproject.org/wiki/Changes/F37Boost178  
> >   in the f37-boost
> > side tag.
> >
> > If your package depends on Boost, or just if you see a "Rebuilt for
> > Boost 1.78" commit pushed to your package's dist-git repo, please
> > co-ordinate with me about any updates to the
> > package. If you need to push other changes to rawhide then you will
> > need to build in the side tag, or we'll have to rebuild it multiple
> > times.
>
> All of the remaining failures:
>
> freecad
>
> /builddir/build/BUILD/FreeCAD-0.19.4/src/Mod/Part/App/BRepOffsetAPI_MakeFillingPyImp.cpp:100:14:
> error: 'unique_ptr' is not a member of 'std'
>100 | std::unique_ptr ptr(new
> BRepOffsetAPI_MakeFilling(degree, nbPtsOnCur, nbIter,
>|  ^~

This is a latent package bug, exposed by GCC 12. It needs to #include
 explicitly to use std::unique_ptr.
https://gcc.gnu.org/gcc-12/porting_to.html#header-dep-changes


> grive2
>  /builddir/build/BUILD/grive2-0.5.1/libgrive/src/base/Syncer.hh:58:22:
> error: 'unique_ptr' in namespace 'std' does not name a template type
> 58 | virtual std::unique_ptr GetFolders() = 0;
>|  ^~

As above.


> guitarix
>  /usr/include/glib-2.0/glib/gatomic.h:163:44: error: invalid conversion
> from ‘volatile void*’ to ‘void*’ [-fpermissive]
>163 | __atomic_compare_exchange_n ((atomic), _oldval,
> (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
>|^~

Huh, I thought we fixed this in Glib. Unrelated to Boost anyway, I
think this has been broken since GCC 11.


> libzypp
>  /builddir/build/BUILD/libzypp-17.25.6/zypp/target/rpm/RpmHeader.cc: In
> function 'int unameToUid(const char*, uid_t*)':
>  /builddir/build/BUILD/libzypp-17.25.6/zypp/target/rpm/RpmHeader.cc:41:16:
> error: 'strcmp' was not declared in this scope
> 41 | } else if (strcmp(thisUname, "root") == 0) {
>|^~

Looks like a package bug.


> vsomeip3
> /builddir/build/BUILD/vsomeip-3.1.20.3/implementation/endpoints/src/endpoint_impl.cpp:8:10:
> fatal error: boost/asio/ip/udp_ext.hpp: No such file or directory
>  8 | #include 
>|  ^~~

This one might be due to the new Boost.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: mingw-gcc-12.0.1 and mingw-binutils-2.38 coming to rawhide

[Jonathan Wakely]

On Thu, 24 Mar 2022 at 08:49, Sandro Mani wrote:
>
>
> On 14.03.22 23:50, Sandro Mani wrote:
> > Hi
> >
> > As per [1] I'll be landing mingw-gcc-12.0.1 and mingw-binutils-2.38
> > towards the end of the week. I've completed test-builds here [2].
>
> Looks like there is an ABI incompatibility (std::__once_functor went
> away), I'll need to rebuild all dependent mingw packages:

FWIW this means mingw now supports TLS and this libstdc++-internal
macro changed value:
#ifdef _GLIBCXX_HAVE_TLS

That causes libstdc++ to use a different definition of std::call_once,
without the std::__once_functor global.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: FESCo wants to know what you use i686 packages for

[Jonathan Wakely]

On Wed, 16 Mar 2022 at 14:25, Jakub Jelinek wrote:
>
> On Wed, Mar 16, 2022 at 09:54:12AM -0400, David Cantrell wrote:
> > If you use i686 packages for something now, please respond to this thread.
>
> I use {glibc{,-devel,-static},{gmp,mpfr,libmpc}{,-devel}}.i686 for
> development and testing of GCC, even in Fedora packages I'd strongly prefer
> to keep the -m32 support around which also requires at least those packages
> (well, currently it requires far more so that it can build documentation
> etc.).

I'm a bit late to this thread, but I also use glibc i686 packages for
upstream GCC development and testing. I build a 64-bit GCC and test
with -m32 so I think I only need the 32-bit glibc packages for that.

I would prefer not to have to do that in a container using a different distro.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Problem with cmake 3.23.0

[Jonathan Wakely]

On Fri, 4 Mar 2022 at 14:26, Steven A. Falco  wrote:
>
> There is a new FTBFS for KiCad [1].  I filed an issue with KiCad [2] and got 
> a comment from the project leader:
>
>  This looks like cmake issue to me. For some reason cmake is creating an 
> incorrect build folder:
>
>  -- Build files have been written to: /builddir/build/BUILD/kicad-6.0.2
>
>  so the build command:
>
>  + /usr/bin/cmake --build redhat-linux-build -j6 --verbose
>
>  cannot find the redhat-linux-build folder that was passed on the cmake 
> command line.
>
> In the last successful build, we have:
>
>-- Build files have been written to: 
> /builddir/build/BUILD/kicad-6.0.2/redhat-linux-build
>+ /usr/bin/cmake --build redhat-linux-build -j6 --verbose
>
> For some reason, the build file directory has changed:
>
> Success case: /builddir/build/BUILD/kicad-6.0.2/redhat-linux-build
> Failure case: /builddir/build/BUILD/kicad-6.0.2
>
> Is this a bug in cmake or did something in RPM macros change?

Whatever it is seems to have broken a number of packages, including

FlightCrew, csdiff, libphonenumber, ledger, blas

Those are just the ones that need to be rebuilt for a new Boost and so
were tested by Tom Rodgers, there are probably a lot more that he
didn't find.

The ones I've checked all do "%cmake ." or "%cmake some_dir"

Some fail during the %cmake step, and some fail during %cmake_build.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 36 Mass Branching

[Jonathan Wakely]

On Mon, 14 Feb 2022 at 18:14, Kevin Fenzi  wrote:
>
> On Mon, Feb 14, 2022 at 03:30:52PM +, Jonathan Wakely wrote:
> >
> > I can't see how "rawhide/f36 has been completely isolated from
> > previous releases" can be interpreted to mean that :-)
>
> Well, long ago when we branched, there was a inheritence chain in koji,
> so if you built something in F(n-1) it just got inherited into F(n).
> So, ie, if you built foo-1.0-1.fc36 it would just also appear in rawhide
> until you specifically did a rawhide build). This just caused a lot of
> problems, and I think this announcement dates back to when that just
> happened. So, now it's causing confusion the other way. :)

My point is more that "rawhide/f36 has been isolated" makes no sense.
Note it's phrased as singular, as though "rawhide slash f36" is a
single thing. It's not, it's two branches now. Does it mean "rawhide
and f36 have been isolated"? Or "rawhide/f37"? The confusion is not
because of historical practice, it's because the words just don't make
any sense.


>
> > f36 was already isolated from f35 and the other previous releases.
> > rawhide has now been isolated from f36 (which is not a release).
> >
> > How about rewording it as:
> >
> > "Fedora 36 has now been branched, please be sure to do a git fetch
> > to pick up the new branch. As f36 and rawhide are now separate branches,
> > anything you do for f36 must also be done in the rawhide branch."
> >
> > (This seems backwards for my workflow. If I wanted to make a change on
> > both rawhide and f36 I'd do it in rawhide and do a fast-forward merge
> > to get it on the f36 branch, but this announcement probably isn't the
> > place to be giving people tips on git workflow.)
> >
> > The next part seems OK ...
> >
> > "There will be a Fedora 36 compose and it'll appear in
> > http://dl.fedoraproject.org/pub/fedora/linux/development/36/ once
> > complete. Please be sure to check it out."
> >
> > Although I'd avoid the contraction "it'll" and I'm not sure what
> > "check it out" means. Is it telling me to checkout a Git branch?
> > Because that's how it could be interpreted. I think it's telling me to
> > try the 36 compose. "Please be sure" sounds like this is something I
> > *should* be doing as a package maintainer, but I'm afraid I never
> > routinely try pre-release composes. Maybe it should simply encourage
> > people to try it, not sound like it's compulsory.
>
> Yeah, I am going to get all these announcements checked into git and
> adjusted. Thanks for the good feedback on it.

Great, thanks!
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 36 Mass Branching

[Jonathan Wakely]

On Wed, 9 Feb 2022 at 18:15, Kevin Fenzi  wrote:
>
> On Wed, Feb 09, 2022 at 06:26:44PM +0100, Fabio Valentini wrote:
> > On Wed, Feb 9, 2022 at 6:12 PM Jonathan Wakely  wrote:
> > >
> > > On Tue, 8 Feb 2022 at 20:40, Tomas Hrcka  wrote:
> > > >
> > > > Hi All,
> > > >
> > > > Fedora 36 has now been branched, please be sure to do a git pull
> > > > --rebase to pick up the new branch, as an additional reminder
> > > > rawhide/f36 has been completely isolated from previous releases, so
> > >
> > > What does this mean?
> > >
> > > > this means that anything you do for f36 you also have to do in the
> > > > rawhide branch and do a build there.
> > >
> > > Right, f36 is a separate branch from rawhide now. That makes sense.
> > > What does "rawhide/f36 has been completely isolated from previous
> > > releases" mean? If it's trying to say "rawhide and f36 are now
> > > separate branches" it fails to do so. Is it supposed to say
> > > rawhide/f37?
> >
> > Yeah, that template sounds really archaic by todays standards, and
> > it's at least misleading or even wrong in some regards.
> > So it could benefit from being updateg ... Is it maintained in a
> > public repo somewhere where one could submit a PR to fix it? :)
>
> Well, it means _builds_ are not inherited between them.
>
> Long ago we used to let branched inherit into rawhide until there was a
> branched build. This turned out to cause a number of problems so we
> stopped doing it. So now if you do a f36 build, you need to also make
> sure to do a f37 one as well.

I can't see how "rawhide/f36 has been completely isolated from
previous releases" can be interpreted to mean that :-)

f36 was already isolated from f35 and the other previous releases.
rawhide has now been isolated from f36 (which is not a release).

How about rewording it as:

"Fedora 36 has now been branched, please be sure to do a git fetch
to pick up the new branch. As f36 and rawhide are now separate branches,
anything you do for f36 must also be done in the rawhide branch."

(This seems backwards for my workflow. If I wanted to make a change on
both rawhide and f36 I'd do it in rawhide and do a fast-forward merge
to get it on the f36 branch, but this announcement probably isn't the
place to be giving people tips on git workflow.)

The next part seems OK ...

"There will be a Fedora 36 compose and it'll appear in
http://dl.fedoraproject.org/pub/fedora/linux/development/36/ once
complete. Please be sure to check it out."

Although I'd avoid the contraction "it'll" and I'm not sure what
"check it out" means. Is it telling me to checkout a Git branch?
Because that's how it could be interpreted. I think it's telling me to
try the 36 compose. "Please be sure" sounds like this is something I
*should* be doing as a package maintainer, but I'm afraid I never
routinely try pre-release composes. Maybe it should simply encourage
people to try it, not sound like it's compulsory.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: How to clone by fedpkg ?

[Jonathan Wakely]

On Fri, 11 Feb 2022 at 09:20, Miao, Jun  wrote:
>
> Hi developer,
>
> I want to clone the rpms through fedpkg, but failed log like this:
>
>
>
> jmiao@fedora36:temp$ fedpkg clone tboot
>
> Cloning into 'tboot'...
>
> miaojun0...@pkgs.fedoraproject.org: Permission denied (publickey).
>
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
>
> and the repository exists.
>
> Could not execute clone: Failed to execute command.
>
>
>
> I have kinit right successfully and I am the commit member of the tboot rpms.
>
> Whether I must be a admin of this rpms, even  I want to clone it?


You can do an anonymous clone using 'fedpkg clone -a tboot' (but of
course them you wouldn't be able to push changes, unless you edit the
URL of the git remote).

To be able to do non-anonymous clones or to push you need to be
authenticated, as Artur said.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora 36 Mass Branching

[Jonathan Wakely]

On Tue, 8 Feb 2022 at 20:40, Tomas Hrcka  wrote:
>
> Hi All,
>
> Fedora 36 has now been branched, please be sure to do a git pull
> --rebase to pick up the new branch, as an additional reminder
> rawhide/f36 has been completely isolated from previous releases, so

What does this mean?

> this means that anything you do for f36 you also have to do in the
> rawhide branch and do a build there.

Right, f36 is a separate branch from rawhide now. That makes sense.
What does "rawhide/f36 has been completely isolated from previous
releases" mean? If it's trying to say "rawhide and f36 are now
separate branches" it fails to do so. Is it supposed to say
rawhide/f37?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)

[Jonathan Wakely]

On Wed, 9 Feb 2022 at 11:00, Neal Gompa  wrote:
>
> On Wed, Feb 9, 2022 at 5:24 AM Jonathan Wakely  wrote:
> >
> > On Tue, 18 Jan 2022 at 14:30, Ben Cotton  wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
> > >
> > > = Wayland by Default for SDDM =
> > >
> > > == Summary ==
> > > Change the default display server mode for SDDM to use a Wayland-based
> > > greeter rather than an X11-based one.
> > >
> > > == Owner ==
> > > * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
> > > [[User:Jgrulich|Jan Grulich]]
> > > * Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com
> > > * Product: KDE Spin, Kinoite
> > > * Responsible WG: KDE SIG
> > >
> > >
> > > == Detailed Description ==
> > > With [https://github.com/sddm/sddm/pull/1393 the work done upstream in
> > > SDDM to support using a Wayland based greeter] and
> > > [[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the
> > > broken fallback when platform drivers are unavailable]], it is now
> > > possible for the Fedora KDE variants (the regular spin and Kinoite) to
> > > move to Wayland for the login manager, which effectively completes the
> > > switch to Wayland for these variants.
> > >
> > >
> > > == Benefit to Fedora ==
> > > As originally detailed in [[Changes/WaylandByDefaultForPlasma|the
> > > Change to switch Plasma to Wayland by default]], Fedora is a leader in
> > > advancing the adoption of the Wayland protocol as part of the overall
> > > strategy to improve the Linux graphical software stack. We have been
> > > successful in helping drive Wayland forward in the Plasma Desktop, and
> > > we intend to do the same for SDDM.
> > >
> > > == Scope ==
> > > * Proposal owners:
> > > ** Upgrade {{package|sddm}} to the latest snapshot and introduce
> > > mutually exclusive sddm-wayland-generic and
> > > sddm-x11 greeter configuration packages.
> > > ** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
> > > *** Enable installation of the SDDM Wayland configuration snippet and
> > > ship as sddm-wayland-plasma that is mutually exclusive
> > > with the other sddm greeter configuration packages. This package will
> > > supplement {{package|sddm}} and plasma-workspace-wayland
> > > to be automatically installed together.
> > > ** Modify @kde-desktop comps group for Fedora Linux 36 to
> > > include sddm-wayland-plasma for the media.
> > >
> > >
> > > * Other developers: N/A (not needed for this Change)
> > >
> > > * Release engineering: [https://pagure.io/releng/issue/10536 #10536]
> > > * Policies and guidelines: N/A (not needed for this Change)
> > > * Trademark approval: N/A (not needed for this Change)
> > > * Alignment with Objectives: N/A
> > >
> > >
> > > == Upgrade/compatibility impact ==
> > > On upgrade to Fedora Linux 36, SDDM will be transparently switched
> > > from the X11 greeter to the Wayland one leveraging kwin. In order to
> > > override this, the user can do one of the following:
> > > * Drop in a configuration file in /etc/sddm.conf.d to set
> > > the display server back to X11
> > > * Swap back to X11 with the configuration package: dnf swap
> > > sddm-wayland-plasma sddm-x11
> > >
> > >
> > > == How To Test ==
> > > Once the SDDM and Plasma Wayland changes are made, Rawhide users can
> > > try this by using nightly KDE ISOs and using them normally to install
> > > and run a Rawhide KDE Plasma environment.
> > >
> > > == User Experience ==
> > > Ideally, there should be no noticeable impact on the user experience,
> > > though users may notice that things operate more smoothly and with
> > > slightly lower resources.
> >
> >
> > Last time I tried, I couldn't use Synergy and Wayland together, so I
> > use X11 sessions with KDE still. Will this change only affect the
> > pre-login greeter screen, or does it also affect the lock screen when
> > a running X11 session is locked (either explicitly or after the
> > timeout)? Currently I can still use the mouse and keyboard from a
> > different machine to unlock that lock screen. If it starts using
> > Wayland that won't work. It might be worth mentioning that for the
> > user experience for other Synergy users.
>
> SDDM only affects pre-login, just like GDM for GNOME. If you select
> X11 at login, the lock screen will also use X11.

Great, thanks!
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Wayland by Default for SDDM (Self-Contained Change proposal)

[Jonathan Wakely]

On Tue, 18 Jan 2022 at 14:30, Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM
>
> = Wayland by Default for SDDM =
>
> == Summary ==
> Change the default display server mode for SDDM to use a Wayland-based
> greeter rather than an X11-based one.
>
> == Owner ==
> * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]],
> [[User:Jgrulich|Jan Grulich]]
> * Email: ngomp...@gmail.com, rdie...@gmail.com, jgrul...@redhat.com
> * Product: KDE Spin, Kinoite
> * Responsible WG: KDE SIG
>
>
> == Detailed Description ==
> With [https://github.com/sddm/sddm/pull/1393 the work done upstream in
> SDDM to support using a Wayland based greeter] and
> [[Changes/ReplaceFbdevDrivers|the introduction of SimpleDRM to fix the
> broken fallback when platform drivers are unavailable]], it is now
> possible for the Fedora KDE variants (the regular spin and Kinoite) to
> move to Wayland for the login manager, which effectively completes the
> switch to Wayland for these variants.
>
>
> == Benefit to Fedora ==
> As originally detailed in [[Changes/WaylandByDefaultForPlasma|the
> Change to switch Plasma to Wayland by default]], Fedora is a leader in
> advancing the adoption of the Wayland protocol as part of the overall
> strategy to improve the Linux graphical software stack. We have been
> successful in helping drive Wayland forward in the Plasma Desktop, and
> we intend to do the same for SDDM.
>
> == Scope ==
> * Proposal owners:
> ** Upgrade {{package|sddm}} to the latest snapshot and introduce
> mutually exclusive sddm-wayland-generic and
> sddm-x11 greeter configuration packages.
> ** Modify {{package|plasma-workspace}} to switch SDDM to Wayland
> *** Enable installation of the SDDM Wayland configuration snippet and
> ship as sddm-wayland-plasma that is mutually exclusive
> with the other sddm greeter configuration packages. This package will
> supplement {{package|sddm}} and plasma-workspace-wayland
> to be automatically installed together.
> ** Modify @kde-desktop comps group for Fedora Linux 36 to
> include sddm-wayland-plasma for the media.
>
>
> * Other developers: N/A (not needed for this Change)
>
> * Release engineering: [https://pagure.io/releng/issue/10536 #10536]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: N/A
>
>
> == Upgrade/compatibility impact ==
> On upgrade to Fedora Linux 36, SDDM will be transparently switched
> from the X11 greeter to the Wayland one leveraging kwin. In order to
> override this, the user can do one of the following:
> * Drop in a configuration file in /etc/sddm.conf.d to set
> the display server back to X11
> * Swap back to X11 with the configuration package: dnf swap
> sddm-wayland-plasma sddm-x11
>
>
> == How To Test ==
> Once the SDDM and Plasma Wayland changes are made, Rawhide users can
> try this by using nightly KDE ISOs and using them normally to install
> and run a Rawhide KDE Plasma environment.
>
> == User Experience ==
> Ideally, there should be no noticeable impact on the user experience,
> though users may notice that things operate more smoothly and with
> slightly lower resources.


Last time I tried, I couldn't use Synergy and Wayland together, so I
use X11 sessions with KDE still. Will this change only affect the
pre-login greeter screen, or does it also affect the lock screen when
a running X11 session is locked (either explicitly or after the
timeout)? Currently I can still use the mouse and keyboard from a
different machine to unlock that lock screen. If it starts using
Wayland that won't work. It might be worth mentioning that for the
user experience for other Synergy users.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: MinGW UCRT target (Self-Contained Change proposal)

[Jonathan Wakely]

On Mon, 7 Feb 2022 at 17:10, Neal Gompa wrote:
>
> On Mon, Feb 7, 2022 at 11:20 AM Kevin Kofler via devel
>  wrote:
> >
> > Marc-André Lureau wrote:
> > > Release build should be tested on Windows. It is easy to build and test
> > > natively with msys2 nowadays, or build for other targets. Why not use
> > > that?
> >
> > Because I do not have a computer running Windows, nor a Windows license.
> >
>
> For my hobbyist game development, I rely on the Fedora MinGW stack to
> be able to produce Windows builds for them. I do all my own
> development and work from Fedora Linux and I'd rather not change that.
>
> If anything, our MinGW stack is an amazing selling point compared to
> other distributions, because we provide a usable framework to build
> applications for Windows.

It really is great. GCC's C++17 std::filesystem code supports Windows,
but is entirely developed on Fedora. I cross-compile using mingw-w64
and test using Wine. If I couldn't do that on Fedora, the Windows
support simply wouldn't exist.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Weirdness with clang and stdatomic.h on Rawhide

[Jonathan Wakely]

On Fri, 4 Feb 2022 at 22:26, Ron Olson  wrote:
>
> Oh, I forgot I could test for Clang too…I tried that fix and it works for me. 
> :)


It's on GCC trunk now, at commit https://gcc.gnu.org/r12-7064

It should get into rawhide whenever the next gcc update happens.



>
> On 4 Feb 2022, at 13:35, Jonathan Wakely wrote:
>
> > On Thu, 3 Feb 2022 at 20:27, Ron Olson  wrote:
> >>
> >> Here’s a question: what if the following was added to stdatomic.h at the 
> >> end of the file:
> >>
> >> #else
> >> #include_next 
> >> #endif // C++23
> >>
> >> Since the rest of the file is gated by C++23, this allows C++ programs 
> >> that reference this header to have a chance to pick up the Clang one, if 
> >> it exists. If Clang isn’t installed, it doesn’t matter insofar as the C++ 
> >> program is going to fail anyway because it hasn’t explicitly set 
> >> -std=c++2b.
> >
> > That will fail miserably with GCC, because the C library's
> >  cannot be included in C++ (because it uses C features
> > that are not valid in C++).
> >
> > But I'll test:
> >
> > #elif defined __clang__
> > #include_next 
> > ___
> > 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 on the list, report it: 
> > https://pagure.io/fedora-infrastructure
> ___
> 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 on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Weirdness with clang and stdatomic.h on Rawhide

[Jonathan Wakely]

On Thu, 3 Feb 2022 at 20:27, Ron Olson  wrote:
>
> Here’s a question: what if the following was added to stdatomic.h at the end 
> of the file:
>
> #else
> #include_next 
> #endif // C++23
>
> Since the rest of the file is gated by C++23, this allows C++ programs that 
> reference this header to have a chance to pick up the Clang one, if it 
> exists. If Clang isn’t installed, it doesn’t matter insofar as the C++ 
> program is going to fail anyway because it hasn’t explicitly set -std=c++2b.

That will fail miserably with GCC, because the C library's
 cannot be included in C++ (because it uses C features
that are not valid in C++).

But I'll test:

#elif defined __clang__
#include_next 
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Weirdness with clang and stdatomic.h on Rawhide

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 15:00, Ron Olson wrote:
>
> Well, yes and no. The code I linked to in the pastebin is what demonstrates 
> the issue. The code in question is Apple’s libdispatch which I package 
> separately as well as part of Swift. In that situation they’re using a C++ 
> file that uses the underlying primitives in stdatomic in macros for their own 
> higher-level functions, thus why stdatomic is ultimately being invoked.

Does this help?

https://github.com/apple/swift-corelibs-libdispatch/compare/main...jwakely:patch-1
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Uninitialized variables and F37

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 12:03, Florian Weimer  wrote:
>
> * Jonathan Wakely:
>
> > Vitaly, it looks like you didn't respond to this. I'm also curious why
> > this change would lead to crashes. Are we missing something?
>
> I've seen cases where access to uninitialized data was fine as long as
> the memory location was never zero, something that was always true for
> how GCC compiled the program at the time.

Ah, so uninitialized pointers that were non-zero, and so reading from
some arbitrary mapped page. If the pointer gets initialized to zero
reading from it would be a segfault, because the zero page isn't
mapped.

That seems like an improvement, and worth finding and fixing the code.
"Maintainers should not have to fix bugs in their packages" seems like
a totally bogus argument to me.

>
> But I most say that I find the other direction more likely (as in, the
> program is fine because it works correctly on Fedora).
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Announcing LLVM Snapshot Packages for Fedora Linux

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 11:25, Jonathan Wakely  wrote:
>
> On Thu, 27 Jan 2022 at 16:29, José Abílio Matos  wrote:
> >
> > On Thursday, 27 January 2022 16.14.36 WET José Abílio Matos wrote:
> >
> > > $ src/lyx
> >
> > >
> >
> > > [1] 61542
> >
> > >
> >
> > > src/lyx: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found 
> > > (required
> >
> > > by src/lyx)
> >
> > >
> >
> > >
> >
> > > Any help here?
> >
> >
> > OK, one option is set the linker path
> >
> > $ LD_LIBRARY_PATH=/opt/gcc-latest/lib64/ src/lyx
>
> See the docs: 
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic

Which is also mentioned at https://jwakely.github.io/pkg-gcc-latest/
so I've added a link to that page from the copr description.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Announcing LLVM Snapshot Packages for Fedora Linux

[Jonathan Wakely]

On Thu, 27 Jan 2022 at 16:29, José Abílio Matos  wrote:
>
> On Thursday, 27 January 2022 16.14.36 WET José Abílio Matos wrote:
>
> > $ src/lyx
>
> >
>
> > [1] 61542
>
> >
>
> > src/lyx: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.30' not found (required
>
> > by src/lyx)
>
> >
>
> >
>
> > Any help here?
>
>
> OK, one option is set the linker path
>
> $ LD_LIBRARY_PATH=/opt/gcc-latest/lib64/ src/lyx

See the docs: 
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Uninitialized variables and F37

[Jonathan Wakely]

On Sat, 22 Jan 2022 at 14:58, Richard W.M. Jones wrote:
>
> On Sat, Jan 22, 2022 at 12:36:01PM +0100, Vitaly Zaitsev via devel wrote:
> > On 21/01/2022 19:04, Steve Grubb wrote:
> > >Uninitialized variables are a big problem.
> >
> > Yes, but as a package maintainer, I don't want to deal with dozens
> > of crashes after this change.
> >
> > Such problems must be fixed by upstream developers, not by
> > volunteers [package maintainers].
> >
> > Most upstreams will close such bug reports with "Fedora specific
> > issue" reason, as it was with GLIB assertions. I've manually fixed
> > many of them in my packages.
>
> I'm curious here how you think programs could crash with the proposed
> changes.

Vitaly, it looks like you didn't respond to this. I'm also curious why
this change would lead to crashes. Are we missing something?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Uninitialized variables and F37

[Jonathan Wakely]

On Fri, 28 Jan 2022 at 16:40, Steve Grubb  wrote:
>
> >> Of course gcc -fsanitize=undefined cannot be used on production code.
> >
> > Why not? Will it find too many errors?
>
> This discussion is at least 5 years old:
>
> https://seclists.org/oss-sec/2016/q1/363
>
> I don't know if the problems have been addressed or if new problems have
> popped up. The short of it, if you don't read the link above, is that you can
> use the _OPTIONS environmental variable with a setuid application and clobber
> any file on the file system.

(That's about ASan, but UBSAN_OPTIONS will do the same.)

It's worth noting that -fsanitize=undefined
-fsanitize-undefined-trap-on-error doesn't use UBSAN_OPTIONS and
doesn't require libubsan.so. With the trap-on-error option you just
get a crash instead of a user-friendly description of the error, but
it does still check for UB and halt the process when it's detected.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Weirdness with clang and stdatomic.h on Rawhide

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 09:15, Jonathan Wakely  wrote:
>
> On Mon, 31 Jan 2022 at 22:45, Ron Olson  wrote:
> >
> > Hey all,
> >
> > I’m troubleshooting an issue and came up with this sample program: 
> > https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 
> > 13, on Rawhide, won’t compile that program, while on Fedora 35 it does.
> >
> > The reason why is that on Rawhide, stdatomic.h exists under 
> > /usr/include/c++/12 while it does not exist on 35, so clang uses its 
> > built-in stdatomic per 
> > https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations.
>
> But that's about C, not C++.
>
> >If it uses its internal version, the sample program compiles fine.
> >
> > Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 
> > 202002L”, so that means C++2b or later, not C++20. This seems to create a 
> > problem for clang which, since the file is present, wants to use it, but 
> > since it’s effectively empty due to the #ifdef, compiling of the sample 
> > program fails.
> >
> > Is it possible to disable clang’s use of the header file as a flag? I’ve 
> > been unable to find anything like that, and obviously renaming the header 
> > is out of the question.  Also, is it correct to the setting stdatomic.h to 
> > only be used by c++2b?
>
> Yes, that's 100% correct.
>
> Clang is at fault here.  does not exist in C++ up to and
> including the current C++20 standard, so Clang should not assume it's
> present or usable.
>
> In C++23 there is now a  header in the C++ library for
> compatibility. That's what I added to GCC, and that's what Clang is
> now picking up.
>
> Why is C++ code in Clang using a C header that isn't part of C++?

I think I misread, this isn't code in Clang, this is your code and
you're just using Clang, right?

So then you can fix your code fairly easily.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Weirdness with clang and stdatomic.h on Rawhide

[Jonathan Wakely]

On Tue, 1 Feb 2022 at 09:15, Jonathan Wakely  wrote:
>
> On Mon, 31 Jan 2022 at 22:45, Ron Olson  wrote:
> >
> > Hey all,
> >
> > I’m troubleshooting an issue and came up with this sample program: 
> > https://pastebin.com/g9S8Z64q to demonstrate the problem.

That's not a valid C++ program, even in C++23 after  is added.

For C++23 it needs to be _Atomic(int) because in C++ _Atomic is not a
type qualifier (unlike in C). Clang supports the _Atomic qualifier in
C++ mode, but that's non-standard.

This code is not portable to any compiler except Clang, and is no
longer even portable to Clang when using G++ in C++23 mode.

I suppose we could enable the contents of  for the
non-strict -std=gnu++XX modes before C++23, but you'd still need to
adjust your program to use _Atomic(int) instead of _Atomic int.

Why not just write it in proper C++, using std::atomic or the
atomic_int typedef instead?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Weirdness with clang and stdatomic.h on Rawhide

[Jonathan Wakely]

On Mon, 31 Jan 2022 at 22:45, Ron Olson  wrote:
>
> Hey all,
>
> I’m troubleshooting an issue and came up with this sample program: 
> https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 
> 13, on Rawhide, won’t compile that program, while on Fedora 35 it does.
>
> The reason why is that on Rawhide, stdatomic.h exists under 
> /usr/include/c++/12 while it does not exist on 35, so clang uses its built-in 
> stdatomic per 
> https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations.

But that's about C, not C++.

>If it uses its internal version, the sample program compiles fine.
>
> Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 
> 202002L”, so that means C++2b or later, not C++20. This seems to create a 
> problem for clang which, since the file is present, wants to use it, but 
> since it’s effectively empty due to the #ifdef, compiling of the sample 
> program fails.
>
> Is it possible to disable clang’s use of the header file as a flag? I’ve been 
> unable to find anything like that, and obviously renaming the header is out 
> of the question.  Also, is it correct to the setting stdatomic.h to only be 
> used by c++2b?

Yes, that's 100% correct.

Clang is at fault here.  does not exist in C++ up to and
including the current C++20 standard, so Clang should not assume it's
present or usable.

In C++23 there is now a  header in the C++ library for
compatibility. That's what I added to GCC, and that's what Clang is
now picking up.

Why is C++ code in Clang using a C header that isn't part of C++?
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

[Jonathan Wakely]

On Sat, 22 Jan 2022 at 11:51, Jonathan Wakely  wrote:
>
> On Sat, 22 Jan 2022 at 10:52, Andreas Schneider  wrote:
> >
> > On Tuesday, January 11, 2022 7:00:22 PM CET Steve Grubb wrote:
> > > Hello,
> > >
> > > On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote:
> > >
> > > > https://fedoraproject.org/wiki/Changes/GNUToolchainF36
> > > >
> > > > == Summary ==
> > > > Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
> > > >
> > > > The gcc 12 is currently under development and will be included in
> > > > Fedora 36 upon release. The glibc 2.35 change will be tracked in this
> > > > top-level GNU Toolchain system-wide update.
> > >
> > >
> > > Reading through the GCC 12 changes, there is a significant new feature to
> > > GCC
> >  that would appear to be useful for security. There is a new:
> > >
> > > -ftrivial-auto-var-init=zero
> > >
> > > flag that initializes all stack variables to zero. Zero being a nice safe
> > > value that makes programs crash instead of being exploitable.
> > >
> > > Are there plans to enable this flag so that all applications, but more
> > > importantly the kernel, are hardened against uninitialized stack 
> > > variables?
> > >
> > > This is one of the major classes of security bugs that could potentially
> > > be eliminated during this mass rebuild.
> >
> > I don't know if it is still the case, but OpenSSL used uninitialized stack
> > variables on purpose! If you initialize them to zero might end up with the
> > same disaster as Debian had some years ago!
> >
> > https://www.debian.org/security/2008/dsa-1571
>
> IIRC it wasn't that simple. The necessary entropy was *not* coming
> from uninitialized bytes. There were other sources of *real* entropy,
> but the Debian patch caused *none* of it to be added to the pool
> (except for the PID). Zeroing the uninitialized bytes would *not* hurt
> as long as the *real* sources of entropy still get added.

Also, I think the count of added entropy was still being updated even
though nothing got added.

The bug was more complicated than just "an uninitialized stack buffer
didn't get used as entropy".
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: GNU Toolchain Update (gcc 12, glibc 2.35) (late System-Wide Change proposal)

[Jonathan Wakely]

On Sat, 22 Jan 2022 at 10:52, Andreas Schneider  wrote:
>
> On Tuesday, January 11, 2022 7:00:22 PM CET Steve Grubb wrote:
> > Hello,
> >
> > On Wednesday, January 5, 2022 5:05:26 PM EST Ben Cotton wrote:
> >
> > > https://fedoraproject.org/wiki/Changes/GNUToolchainF36
> > >
> > > == Summary ==
> > > Update the Fedora 36 GNU Toolchain to gcc 12 and glibc 2.35.
> > >
> > > The gcc 12 is currently under development and will be included in
> > > Fedora 36 upon release. The glibc 2.35 change will be tracked in this
> > > top-level GNU Toolchain system-wide update.
> >
> >
> > Reading through the GCC 12 changes, there is a significant new feature to
> > GCC
>  that would appear to be useful for security. There is a new:
> >
> > -ftrivial-auto-var-init=zero
> >
> > flag that initializes all stack variables to zero. Zero being a nice safe
> > value that makes programs crash instead of being exploitable.
> >
> > Are there plans to enable this flag so that all applications, but more
> > importantly the kernel, are hardened against uninitialized stack variables?
> >
> > This is one of the major classes of security bugs that could potentially
> > be eliminated during this mass rebuild.
>
> I don't know if it is still the case, but OpenSSL used uninitialized stack
> variables on purpose! If you initialize them to zero might end up with the
> same disaster as Debian had some years ago!
>
> https://www.debian.org/security/2008/dsa-1571

IIRC it wasn't that simple. The necessary entropy was *not* coming
from uninitialized bytes. There were other sources of *real* entropy,
but the Debian patch caused *none* of it to be added to the pool
(except for the PID). Zeroing the uninitialized bytes would *not* hurt
as long as the *real* sources of entropy still get added.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Build failure in Clementine due to GCC 12

[Jonathan Wakely]

On Fri, 21 Jan 2022 at 17:42, Jonathan Wakely  wrote:
>
> On Fri, 21 Jan 2022 at 16:37, Robert-André Mauchin  wrote:
> >
> > On 1/21/22 14:46, Robert-André Mauchin wrote:
> > > Hello,
> > >
> > > So I built Clementine last week with no issue, but it failed during
> > > the mass rebuild with the folloing error:
> > >
> > > In file included from 
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
> > >from 
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
> > >  In instantiation of 'WorkerPool::WorkerPool(QObject*) [with 
> > > HandlerType = AbstractMessageHandler]':
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
> > > required from here
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
> > >  error: passing 'QString' as 'this' argument discards qualifiers 
> > > [-fpermissive]
> > > 168 |   local_server_name_ = qApp->applicationName().toLower();
> > > |   ^
> > > In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
> > >from /usr/include/qt5/QtCore/qlist.h:47,
> > >from /usr/include/qt5/QtCore/qstringlist.h:41,
> > >from /usr/include/qt5/QtCore/QStringList:1,
> > >from 
> > > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
> > > /usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
> > > QString::toLower() &&'
> > > 510 | Q_REQUIRED_RESULT QString toLower() &&
> > > |   ^~~
> > >
> > >
> > > Nothing stands up to me in the linked code:
> > >
> > > template 
> > > WorkerPool::WorkerPool(QObject* parent)
> > >  : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
> > >worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
> > >local_server_name_ = qApp->applicationName().toLower();
> > >
> > >if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
> > > }
> > >
> > >
> > > Anyone knows if a flag, or compiler, has changed since last week? Or have 
> > > any input at all?
> > >
> > > Best regards,
> > >
> > > Robert-André
> >
> > So the problem is specific to GCC 12 but I can't find anything in the 
> > changelog related to this.
> > It seems toLower() takes a const as input and qApp->applicationName() is 
> > not a const.
>
> No, you have it backwards.
>
> QString::toLower() && can only be called on a non-const rvalue, and
> applicationName() is apparently returning a const object.
>
> >
> > I solved by replacing
> > local_server_name_ = qApp->applicationName().toLower();
> > to
> > local_server_name_ = QString(qApp->applicationName()).toLower();
>
> This creates an rvalue, which allows the call to toLower().
>
> > Still I would love for a GCC specialist to point me to the relevant change 
> > in GCC 12 so I can
> > send a patch upstream with explanation for the change.
>
> The Qt code has two overloads:
>
> Q_REQUIRED_RESULT QString toLower() const &
> { return toLower_helper(*this); }
> Q_REQUIRED_RESULT QString toLower() &&
> { return toLower_helper(*this); }
>
> For some reason, the second one is being used when it should be the first.
>
> I don't think this is a GCC change though.

I was wrong, this is a weird GCC overload resolution bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104173
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Build failure in Clementine due to GCC 12

[Jonathan Wakely]

On Fri, 21 Jan 2022 at 16:37, Robert-André Mauchin  wrote:
>
> On 1/21/22 14:46, Robert-André Mauchin wrote:
> > Hello,
> >
> > So I built Clementine last week with no issue, but it failed during
> > the mass rebuild with the folloing error:
> >
> > In file included from 
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:29,
> >from 
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:21:
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:
> >  In instantiation of 'WorkerPool::WorkerPool(QObject*) [with 
> > HandlerType = AbstractMessageHandler]':
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.cpp:40:52:
> > required from here
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/ext/libclementine-common/core/workerpool.h:168:55:
> >  error: passing 'QString' as 'this' argument discards qualifiers 
> > [-fpermissive]
> > 168 |   local_server_name_ = qApp->applicationName().toLower();
> > |   ^
> > In file included from /usr/include/qt5/QtCore/qhashfunctions.h:44,
> >from /usr/include/qt5/QtCore/qlist.h:47,
> >from /usr/include/qt5/QtCore/qstringlist.h:41,
> >from /usr/include/qt5/QtCore/QStringList:1,
> >from 
> > /builddir/build/BUILD/Clementine-0be314337d5bbd6fc7f5c76c31d7b87e37ba3a04/src/core/tagreaderclient.h:26:
> > /usr/include/qt5/QtCore/qstring.h:510:31: note:   in call to 'QString 
> > QString::toLower() &&'
> > 510 | Q_REQUIRED_RESULT QString toLower() &&
> > |   ^~~
> >
> >
> > Nothing stands up to me in the linked code:
> >
> > template 
> > WorkerPool::WorkerPool(QObject* parent)
> >  : _WorkerPoolBase(parent), next_worker_(0), next_id_(0) {
> >worker_count_ = qBound(1, QThread::idealThreadCount() / 2, 2);
> >local_server_name_ = qApp->applicationName().toLower();
> >
> >if (local_server_name_.isEmpty()) local_server_name_ = "workerpool";
> > }
> >
> >
> > Anyone knows if a flag, or compiler, has changed since last week? Or have 
> > any input at all?
> >
> > Best regards,
> >
> > Robert-André
>
> So the problem is specific to GCC 12 but I can't find anything in the 
> changelog related to this.
> It seems toLower() takes a const as input and qApp->applicationName() is not 
> a const.

No, you have it backwards.

QString::toLower() && can only be called on a non-const rvalue, and
applicationName() is apparently returning a const object.

>
> I solved by replacing
> local_server_name_ = qApp->applicationName().toLower();
> to
> local_server_name_ = QString(qApp->applicationName()).toLower();

This creates an rvalue, which allows the call to toLower().

> Still I would love for a GCC specialist to point me to the relevant change in 
> GCC 12 so I can
> send a patch upstream with explanation for the change.

The Qt code has two overloads:

Q_REQUIRED_RESULT QString toLower() const &
{ return toLower_helper(*this); }
Q_REQUIRED_RESULT QString toLower() &&
{ return toLower_helper(*this); }

For some reason, the second one is being used when it should be the first.

I don't think this is a GCC change though.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Thu, 20 Jan 2022 at 13:05, Jonathan Wakely  wrote:
>
> On Thu, 20 Jan 2022 at 12:54, Kaleb Keithley  wrote:
> >
> >
> > I thought I'd solved all my gcc-12-isms in ceph by running --scratch 
> > --arch-override=x86_64 builds, so I tried a full build and ran into this on 
> > aarch64. :-(
> >
> > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> > /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> > -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> > -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> > -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> > -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> > -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> > /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> > /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> > -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> > -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> > -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> > -mbranch-protection=standard -fasynchronous-unwind-tables 
> > -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> > -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> > -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> > -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> > -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> > -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> > -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> > -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> > src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> > /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> > In file included from /usr/include/boost/integer.hpp:20,
> >  from /usr/include/boost/integer/integer_mask.hpp:16,
> >  from /usr/include/boost/random/mersenne_twister.hpp:26,
> >  from /usr/include/boost/uuid/random_generator.hpp:17,
> >  from /usr/include/boost/uuid/uuid_generators.hpp:17,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
> >  from 
> > /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
> >  

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Thu, 20 Jan 2022 at 12:54, Kaleb Keithley  wrote:
>
>
> I thought I'd solved all my gcc-12-isms in ceph by running --scratch 
> --arch-override=x86_64 builds, so I tried a full build and ran into this on 
> aarch64. :-(
>
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> FAILED: src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o
> /usr/bin/g++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION 
> -DBOOST_ASIO_USE_TS_EXECUTOR_AS_DEFAULT -DHAVE_CONFIG_H 
> -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT 
> -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ 
> -I/builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/src/include 
> -I/builddir/build/BUILD/ceph-16.2.7/src -isystem 
> /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/include -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/xxHash -isystem 
> /builddir/build/BUILD/ceph-16.2.7/src/rapidjson/include -isystem 
> /usr/include/python3.10 -O2  -fexceptions -g -grecord-gcc-switches -pipe 
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
> -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  
> -mbranch-protection=standard -fasynchronous-unwind-tables 
> -fstack-clash-protection -O2 -g -DNDEBUG -fPIE   -U_FORTIFY_SOURCE -Wall 
> -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers 
> -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas 
> -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 
> -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel 
> -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong 
> -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc 
> -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -MF 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o.d -o 
> src/mgr/CMakeFiles/ceph-mgr.dir/ActivePyModule.cc.o -c 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc
> In file included from /usr/include/boost/integer.hpp:20,
>  from /usr/include/boost/integer/integer_mask.hpp:16,
>  from /usr/include/boost/random/mersenne_twister.hpp:26,
>  from /usr/include/boost/uuid/random_generator.hpp:17,
>  from /usr/include/boost/uuid/uuid_generators.hpp:17,
>  from /builddir/build/BUILD/ceph-16.2.7/src/include/uuid.h:16,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/include/types.h:21,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/msg/msg_types.h:23,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/common/ceph_context.h:36,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/dout.h:29,
>  from /builddir/build/BUILD/ceph-16.2.7/src/common/debug.h:18,
>  from 
> /builddir/build/BUILD/ceph-16.2.7/src/mgr/ActivePyModule.cc:16:
> /usr/include/boost/integer_traits.hpp:83:64: error: narrowing conversion of 
> '255' from 'int' to 'char' [-Wnarrowing]
>83 | public detail::integer_traits_base
>   |
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=81520773
>
> Are we expecting an update to boost by any chance?

No, 

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Jonathan Wakely]

On Tue, 18 Jan 2022 at 11:01, Jonathan Wakely  wrote:

>
>
> On Mon, 17 Jan 2022 at 14:01, Ben Beasley  wrote:
>
>> Skimming through Koschei, here are a sampling of regressions that seem
>> to be associated with GCC 12. Some of these are in packages I maintain
>> directly; others are via @neuro-sig.
>>
>> With a few exceptions, I have triaged these only to the extent of
>> confirming the problem appeared at the same time as GCC 12 and noting
>> the initial error. I mostly haven’t gotten around to filing or searching
>> for bugs, upstream or downstream.
>>
>> Explicit deletion of the
>> std::string(nullptr_t)/std::string_view(nullptr_t) constructors seems
>> like it is going to be a popular cause of FTBFS in C++ packages. Use of
>> this constructor mostly happens implicitly. I think explicit use of the
>> default constructor, e.g. std::string_view(), will usually be the
>> simplest correct substitute.
>>
>
> All such uses were undefined behaviour (and should have thrown an
> exception at runtime if the code was ever executed. Fixing those is good.
>

That change now only applies when compiling as C++23, so won't affect most
packages (once the fix makes it from upstream GCC to rawhide). It would
still be good to fix code that really does construct strings and
string_views from nullptr, otherwise it will break again in a few years
when GCC defaults to -std=gnu++23.




>
>
>> New compilation errors:
>>
>> COPASI: “error: passing 'const CDataVectorN' as 'this'
>> argument discards qualifiers [-fpermissive]”
>>
>
> What's the context? Is that being used as a comparison function in a std::
> container or something?
>
>
>>
>> grpc: initializing std::string_view/absl::string_view with nullptr –
>> fixed and PR sent upstream
>>
>> python-steps: “static assertion failed: key equality predicate must be
>> invocable with two arguments of key type” via
>> c++/12/bits/hashtable_policy.h
>>
>
> Maybe a variant of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103923
>
>
>
>>
>> vxl: “error: conversion from 'int' to 'std::__cxx11::basic_string'
>> is ambiguous” – looks like an attempt to initialize a string by
>> std::string(nullptr), which is now explicitly deleted
>> (“basic_string(nullptr_t) = delete”)
>>
>
> If it's actually initializing it with nullptr, that's just undefined (and
> going to be ill-formed in C++23) and the code should be fixed.
>
> If it's like the nlohmann:json case, I need to investigate more whether
> it's a defect in the C++23 spec or the code should be fixed.
>

Turns out it's both. The C++23 change breaks the json lib (and they have a
fix) but I made it apply to all of C++11/14/17/20/23, which is incorrect
because it breaks code that should be valid in C++20. Fixed in GCC upstream
now.
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure