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
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
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 ==
> >
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
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/
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 buil
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_AS
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
>> d
On Tue, 18 Jan 2022 at 11:04, Jonathan Wakely wrote:
>
>
> On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal
> wrote:
>
>>
>>
>> On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek wrote:
>>
>>> If there are bugs on the compiler side, please let me
On Tue, 18 Jan 2022 at 11:07, Jonathan Wakely wrote:
>
>
> On Tue, 18 Jan 2022 at 11:04, Jonathan Wakely wrote:
>
>>
>>
>> On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 14, 2022 at 3:3
On Tue, 18 Jan 2022 at 11:04, Jonathan Wakely wrote:
>
>
> On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal
> wrote:
>
>>
>>
>> On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek wrote:
>>
>>> If there are bugs on the compiler side, please let me
On Tue, 18 Jan 2022 at 10:29, Frantisek Zatloukal
wrote:
>
>
> On Fri, Jan 14, 2022 at 3:33 PM Jakub Jelinek wrote:
>
>> If there are bugs on the compiler side, please let me know immediately,
>> so that those bugs can be fixed before the mass rebuild next week.
>>
>
> While I was trying to rebu
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 ext
On Mon, 29 Nov 2021 at 19:36, Ben Cotton wrote:
> == Release Notes ==
>
> In the User spoke, the "Make this user administrator" checkbox is now
> checked by default. This improves installation experience for users
> who do not know and need to rely on the default values to guide them.
What's the c
On Tue, 23 Nov 2021 at 17:20, Ben Cotton wrote:
> == Upgrade/compatibility impact ==
> The upgrade should be mostly invisible. It is possible that somebody
> might be relying on some very specific `mlocate` behaviour or parsing
> the `mlocate` database directly, but no such cases are currently
> kn
On Thu, 18 Nov 2021 at 10:36, Dominique Martinet wrote:
>
> Hi Jonathan,
>
> Jonathan Wakely wrote on Wed, Nov 03, 2021 at 01:47:22PM +:
> > And I'll shamelessly plug my copr with weekly GCC snapshots ;-)
> > https://copr.fedorainfracloud.org/coprs/jwakely/gcc-la
On Thu, 25 Nov 2021 at 13:59, David Sommerseth wrote:
> b) By adding the devtoolset as a build dependency, is that enough?
> Will the final .rpm need anything else installed to function? Like a
> newer libstdc++?
No, that's the point of devtoolset, as opposed to just building your
own new GCC. I
On Fri, 8 Oct 2021 at 11:15, Konrad Kleine wrote:
> Dear Fedora packagers, developers and users,
>
> we have some good news for you:
>
> We are beginning to build nightly snapshot packages of LLVM for the latest
> versions of Fedora Linux (currently 34, 35 and rawhide) for a growing list
> of
> a
On Wed, 11 Aug 2021 at 06:01, Ben Beasley wrote:
>
> In general, if you want to rebuild an rpmautospec package with no spec file
> changes, you can do an empty git commit like this:
>
> git commit —allow-empty -m 'Rebuild for foolib 3.14'
>
> Then “fedpkg build” as usual.
This should have been do
On Wed, 11 Aug 2021 at 11:00, Jonathan Wakely wrote:
> The rest were not submitted for a rebuild, for some reason. That's
> cpp-hocon, luminance-hdr, openshadinglanguage, and usd. I'm not sure
> why they didn't get submitted.
Those four packages cannot be updated by rpmde
On Wed, 11 Aug 2021 at 10:21, Jonathan Wakely wrote:
>
> On Tue, 10 Aug 2021 at 18:23, Benjamin Beasley wrote:
> >
> > It looks like none of the packages I maintain or co-maintain that depend on
> > boost-devel were rebuilt before the side tag was merged.
> >
>
On Tue, 10 Aug 2021 at 18:23, Benjamin Beasley wrote:
>
> It looks like none of the packages I maintain or co-maintain that depend on
> boost-devel were rebuilt before the side tag was merged.
>
> Some (luminance-hdr, cpp-hocon) had automated FTI bugs filed; these were
> fixed by a manual rebuild
We are starting the rebuilds for
https://fedoraproject.org/wiki/Changes/F35Boost176 in the f35-boost
side tag.
If your package depends on Boost, or just if you see a "Rebuilt for
Boost 1.76" commit pushed to your package's dist-git repo, please
co-ordinate with me and Tom Rodgers (CC'd) about any
On Tue, 27 Jul 2021 at 15:37, Tomas Hrcka wrote:
>
> Hi all, Per the Fedora 35 schedule[1] we started a mass rebuild for Fedora 35
> on Jul 21st, 2021. We did a mass rebuild for Fedora 35 for:
>
> [...]
> https://fedoraproject.org/wiki/Changes/F35Boost176
This change isn't in rawhide, so the rebu
gt;
> Let me talk a bit about the new C++ time zone API I have been looking
> at with Jonathan Wakely.
>
> Errors based on this will be likely correct e.g. get_tz_dir() from the
> currently proposed C++ API for this (see (2)):
N.B. The functions below are not part of the standardized API
On 18/04/21 23:38 -0700, Luya Tshimbalanga wrote:
On 2021-04-15 6:33 a.m., Jonathan Wakely wrote:
The error for this build is completely different to the errors you
showed above:
/builddir/build/BUILD/LuxCore-luxcorerender_v2.5/include/luxrays/utils/utils.h:40:18:
error: 'std::std
On 14/04/21 16:06 -0700, Luya Tshimbalanga wrote:
Due to a possible change related to GCC, packages like openxr and
luxcorereneder failed to build with these errors:
I don't think there's any relevant change in GCC.
It looks like these packages simply fail to link with -lstdc++fs (or
they have
On 01/04/21 12:36 +0200, Florian Weimer wrote:
* Jonathan Wakely:
On 30/03/21 17:13 +0100, Jonathan Wakely wrote:
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc
On 01/04/21 11:09 +0100, Jonathan Wakely wrote:
On 30/03/21 17:13 +0100, Jonathan Wakely wrote:
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which do not work
On 30/03/21 17:13 +0100, Jonathan Wakely wrote:
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which do not work as
intended, and so will not be present in the
On 31/03/21 18:46 +0200, Dan Horák wrote:
On Wed, 31 Mar 2021 17:42:48 +0100
"Richard W.M. Jones" wrote:
On Wed, Mar 31, 2021 at 05:29:33PM +0100, Richard W.M. Jones wrote:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=64923615
>
> This build has been sat in the "free" state for an hou
On 31/03/21 13:51 +, Gwyn Ciesla via devel wrote:
Yes. https://pagure.io/fedora-infrastructure/issue/9816
And
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5KZBG5ARPD7MIKVHJSFSNO6VE4YPEFGA/
and https://status.fedoraproject.org/
__
On 31/03/21 14:25 +0100, Jonathan Wakely wrote:
On 31/03/21 15:00 +0200, Vitaly Zaitsev via devel wrote:
On 31.03.2021 11:45, Jonathan Wakely wrote:
But I can start the same rebuilds in rawhide now to avoid the version
skew.
Please merge your commit from f34 instead of doing another one
On 31/03/21 15:00 +0200, Vitaly Zaitsev via devel wrote:
On 31.03.2021 11:45, Jonathan Wakely wrote:
But I can start the same rebuilds in rawhide now to avoid the version
skew.
Please merge your commit from f34 instead of doing another one:
fedpkg switch-branch rawhide
git merge f34
Yes
On 31/03/21 11:46 +0200, Florian Weimer wrote:
* Omair Majid:
Hi,
Jonathan Wakely writes:
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which do not work
On 31/03/21 09:10 +0200, Nicolas Chauvet wrote:
Le mar. 30 mars 2021 à 18:13, Jonathan Wakely
a écrit :
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which
On 30/03/21 18:24 -0400, Omair Majid wrote:
Hi,
Jonathan Wakely writes:
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which do not work as
intended, and so
Due to an unplanned ABI break that I caused in libstdc++, I will soon
start to rebuild the packages listed below. This rebuild will remove
references to some symbols in libstdc++.so which do not work as
intended, and so will not be present in the final gcc-11.1.0 release.
See https://bugzilla.red
On 13/03/21 12:59 -0500, Gerald Henriksen wrote:
On Sat, 13 Mar 2021 11:00:12 -0500, you wrote:
On Fri, Mar 12, 2021 at 08:13:07PM -0500, Gerald Henriksen wrote:
You aren't going to change not just the 15+ year habits of how people
refer to Fedora, but the even longer habits of how people call
On 09/03/21 09:15 +, Tomasz Kłoczko wrote:
Some time ago gcc, binutils IIRC received an update for ac 2.71 so at least
those two should be by now off-the-table (Am I right?).
No. GCC has a hard requirement on autoconf-2.69, but the Fedora
package doesn't need to run autoconf for it (that ha
On 10/03/21 03:22 -, Scott Williams wrote:
I'm +1 on "Fedora Linux". I believe it adds clarity, especially when talking with software
vendors. IE, "I'm running Fedora Linux" is less ambiguous than having to explain that Fedora is
Linux after telling your ISP's support, etc., "I'm running
On 08/02/21 14:40 +0100, Milan Crha wrote:
On Mon, 2021-02-01 at 15:03 -0500, Mohan Boddu wrote:
Fedora 34 mass rebuild of rpms is done
Hi,
I just noticed that syncevolution built just fine on the January 30th,
but it is failing to build right now, using the same sources as releng.
I o
On 08/02/21 10:14 -0800, Kevin Fenzi wrote:
Is there really a need for a rawhide-build branch?
What if we just pushed a tag for the commit that built after the build
finishes in koji?
In an earlier reply I did say a tag would also work.
To me, a branch ref seems more natural than a tag that k
On 08/02/21 16:28 +0100, Kevin Kofler via devel wrote:
Jonathan Wakely wrote:
You've completely misunderstood the suggestion.
No, sorry, I understood it completely. I think that you are the one who
completely misunderstood my objection, and also missed the point of the
original post. L
On 04/02/21 05:03 +0100, Kevin Kofler via devel wrote:
Dominik 'Rathann' Mierzejewski wrote:
On Wednesday, 03 February 2021 at 14:29, Kevin Kofler via devel wrote:
But it means that provenpackagers who want to bump and rebuild have to
actually manually look at another branch (rawhide-build).
On 03/02/21 14:29 +0100, Kevin Kofler via devel wrote:
Jonathan Wakely wrote:
Instead of force pushing or reverting anything in the rawhide branch,
why not just have two branches?
Maintainers commit to one branch, and if the build is successful that
branch is automatically merged (as a fast
On 05/02/21 10:08 -0500, Steven A. Falco wrote:
I see that the master to main conversion has happened. I'd like to know the
recommended way to deal with that.
Currently, I'm doing:
git fetch --all
git remote prune origin
git remote set-head origin -a
git checkout main
The above sets origin/
On 29/01/21 10:06 -0800, Michel Alexandre Salim wrote:
On Mon, 2021-01-25 at 10:00 +, Jonathan Wakely wrote:
Tom Rodgers completed the Boost 1.75.0 build for the change
https://fedoraproject.org/wiki/Changes/F34Boost175
and I've rebuilt most of the packages that depend on it.
Some o
On 03/02/21 12:24 -, Martin Gansser wrote:
you mean, this part of the patch can be removed ?
@@ -336,14 +331,14 @@
inline char_traits::char_type*
char_traits::move(char_type* s1, const char_type* s2,
int_type
n)
{
-return (cxxtools::Char*)std::memmove(s1, s2, n *
sizeof
On 31/01/21 10:00 -, Martin Gansser wrote:
The issue has now been resolved with this patch:
+++ include/cxxtools/char.h 2021-01-30 18:28:23.87739 +0100
@@ -68,9 +68,7 @@
typedef int32_t value_type;
//! Constructs a character with a value of 0.
-Ch
On 30/01/21 19:19 +0100, Kevin Kofler via devel wrote:
clime wrote:
So if some other maintainer pushes his work to the server meanwhile,
this will just delete his work? Or what's the idea here?
I guess the safe thing to do would be to wait and see whether that commit
also fails to build (i.e.,
On 29/01/21 10:06 -0600, Richard Shaw wrote:
I'm having an issue with OpenImageIO I don't understand.
The build is failing with a ton of errors like these:
/usr/bin/ld: ../../lib/libOpenImageIO.so.2.2.10: undefined reference to
`Field3D::v1_7::SparseFile::Reference >::openFile()'
/usr/bin/ld: .
On 29/01/21 17:04 +0100, Miro Hrončok wrote:
On 29. 01. 21 16:03, Jonathan Wakely wrote:
So if fedpkg clone just added things to .git/info/exclude there would
be no need to modify every .gitignore file in every repo on every
active branch.
That is already the case \o/
https
On 29/01/21 16:00 +, Tom Hughes via devel wrote:
On 29/01/2021 15:53, Jonathan Wakely wrote:
On 29/01/21 16:47 +0100, Miro Hrončok wrote:
On 25. 01. 21 11:00, Jonathan Wakely wrote:
Tom Rodgers completed the Boost 1.75.0 build for the change
https://fedoraproject.org/wiki/Changes
On 29/01/21 16:47 +0100, Miro Hrončok wrote:
On 25. 01. 21 11:00, Jonathan Wakely wrote:
Tom Rodgers completed the Boost 1.75.0 build for the change
https://fedoraproject.org/wiki/Changes/F34Boost175
and I've rebuilt most of the packages that depend on it...
Hello. I now see a strange
On 29/01/21 09:16 -, Martin Gansser wrote:
Hi,
i am trying to compile cxxtools 2.2.1 [1] on Fedora 34 with gcc11 but this
fails with following error messages [2]
on Fedora build server.
make[2]: Entering directory '/builddir/build/BUILD/cxxtools-2.2.1/src'
/bin/sh ../libtool --tag=CXX --
On 29/01/21 14:56 +, Jonathan Wakely wrote:
On 27/01/21 14:13 -0800, Josh Stone wrote:
On 1/27/21 2:04 PM, Otto Urpelainen wrote:
The other option of not using 'git add .' can also be described as
mentally filtering out all the irrelevant unstaged changes to find the
ones t
On 27/01/21 14:13 -0800, Josh Stone wrote:
On 1/27/21 2:04 PM, Otto Urpelainen wrote:
The other option of not using 'git add .' can also be described as
mentally filtering out all the irrelevant unstaged changes to find the
ones that should actually be added. That adds cognitive burden, slows
th
On 26/01/21 16:52 +0100, Fabio Valentini wrote:
On Tue, Jan 26, 2021 at 4:47 PM Jonathan Wakely
wrote:
On 25/01/21 15:16 +0100, Fabio Valentini wrote:
>On Thu, Jan 21, 2021 at 5:10 PM Jakub Jelinek wrote:
>>
>> On Wed, Jan 20, 2021 at 02:17:28PM -0500, Mohan Boddu wrote:
>&
On 26/01/21 03:12 +0100, Kevin Kofler via devel wrote:
Miro Hrončok wrote:
1. Untested changes
Packager pushes a "simple update" to dist git without checking if it even
builds. It doesn't. Packager has no time to fix this, so they move on for
now. Or they submit a build but never check if it ac
On 25/01/21 11:40 -0500, Matthew Miller wrote:
On Mon, Jan 25, 2021 at 04:43:21PM +0100, Fabio Valentini wrote:
But that would involve at least six new steps that would've to be
automated: 1) Creating a fork on src.fp.o (plus error handling around
already existing forks), 2) Cloning the fork ins
On 25/01/21 19:58 +0100, Miro Hrončok wrote:
On 25. 01. 21 19:32, Robbie Harwood wrote:
It seems to me that this problem would be better solved by making
rebuilds smarter. Instead of building tip of dist-git (which might
never have been build), rebuild the last thing that *was* successfully
bui
On 25/01/21 13:42 -0500, Stephen John Smoogen wrote:
On Mon, 25 Jan 2021 at 13:30, Zbigniew Jędrzejewski-Szmek
wrote:
On Mon, Jan 25, 2021 at 07:19:45PM +0100, Miro Hrončok wrote:
> On 25. 01. 21 19:03, Zbigniew Jędrzejewski-Szmek wrote:
> >On Mon, Jan 25, 2021 at 03:59:43PM +0100, Miro Hrončo
On 25/01/21 15:16 +0100, Fabio Valentini wrote:
On Thu, Jan 21, 2021 at 5:10 PM Jakub Jelinek wrote:
On Wed, Jan 20, 2021 at 02:17:28PM -0500, Mohan Boddu wrote:
> We are delaying the mass rebuild by a day as of now due to bugs in gcc
> and dwz. As of now, we are expecting to start mass rebuil
On 25/01/21 12:33 +, Jonathan Wakely wrote:
rstudio -- error: 'bind' is not a member of 'boost'
http://koji.fedoraproject.org/koji/buildinfo?buildID=1673105
I'm going to look into this.
The patch to add -DBOOST_BIND_GLOBAL_PLACEHOLDERS got removed again a
few
On 25/01/21 12:05 +, Jonathan Wakely wrote:
On 25/01/21 10:00 +, Jonathan Wakely wrote:
Tom Rodgers completed the Boost 1.75.0 build for the change
https://fedoraproject.org/wiki/Changes/F34Boost175
and I've rebuilt most of the packages that depend on it.
The following packages f
On 25/01/21 10:00 +, Jonathan Wakely wrote:
Tom Rodgers completed the Boost 1.75.0 build for the change
https://fedoraproject.org/wiki/Changes/F34Boost175
and I've rebuilt most of the packages that depend on it.
The following packages failed to build. I'll look at the ones that
ap
On 25/01/21 11:41 +0100, Iñaki Ucar wrote:
On Mon, 25 Jan 2021 at 11:31, Iñaki Ucar wrote:
On Mon, 25 Jan 2021 at 11:08, Jonathan Wakely wrote:
>
> Tom Rodgers completed the Boost 1.75.0 build for the change
> https://fedoraproject.org/wiki/Changes/F34Boost175
> and I've re
Tom Rodgers completed the Boost 1.75.0 build for the change
https://fedoraproject.org/wiki/Changes/F34Boost175
and I've rebuilt most of the packages that depend on it.
The following packages failed to build. I'll look at the ones that
appear to be due to Boost changes.
OpenImageIO -- libOpenImag
On 20/01/21 10:47 +, Jonathan Wakely wrote:
On 20/01/21 09:51 -, Martin Gansser wrote:
Hi,
when compiling cxxtools-3.0 on rawhide it fails with the following error
messages [2]:
settingswriter.cpp:42:26: required from here
/usr/include/c++/11/string_view:98:21: error: static
On 20/01/21 09:51 -, Martin Gansser wrote:
Hi,
when compiling cxxtools-3.0 on rawhide it fails with the following error
messages [2]:
settingswriter.cpp:42:26: required from here
/usr/include/c++/11/string_view:98:21: error: static assertion failed
98 | static_assert(is_trivial_v
On 20/01/21 11:31 +0100, Miro Hrončok wrote:
Many Pythons started to fail in Fedora on x86_64 and aarch64 with:
+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv:
s
On 15/12/20 10:36 -0800, Adam Williamson wrote:
Well, the potential problem I see is that you have to *know* the other
list exists. For a new Fedora user this isn't trivial. I've no idea how
people find out about devel@ but I imagine it's linked all over the
intarwebs, having existed for literal
On 15/12/20 23:46 +0100, Miro Hrončok wrote:
On 12/15/20 11:29 PM, Miroslav Suchý wrote:
I am looking for challenges for upcoming year - what I and my team should
enhance. I have some ideas, but I want to hear
yours.
Thanks for doing this!
What you - as Fedora packager - find most time cons
On 10/11/20 23:24 +, Will Crawford wrote:
On Tue, 10 Nov 2020 at 11:56, Sandro Mani wrote:
/usr/bin/ld:
CMakeFiles/vtkIOXMLCxxTests.dir/TestXMLHyperTreeGridIO.cxx.o (symbol
from plugin): undefined reference to symbol
'_ZZNSt8__detail18__to_chars_10_implIjEEvPcjT_E8__digits@@LLVM_11'
/usr/b
On 28/10/20 14:35 +0100, Florian Weimer wrote:
* Jonathan Wakely:
On 28/10/20 13:31 +0100, Florian Weimer wrote:
* Jonathan Wakely:
Dropping GCC 11 into rawhide now would mean I can't make certain
ABI-breaking changes to the C++20 library in upstream GCC, because it
would be landing on
On 28/10/20 13:31 +0100, Florian Weimer wrote:
* Jonathan Wakely:
Dropping GCC 11 into rawhide now would mean I can't make certain
ABI-breaking changes to the C++20 library in upstream GCC, because it
would be landing on real users' machines. Which means I lose several
weeks of GCC
On 23/10/20 13:46 -0400, Neal Gompa wrote:
On Fri, Oct 23, 2020 at 1:07 PM Clement Verna wrote:
On Fri, 23 Oct 2020 at 17:20, Miro Hrončok wrote:
On 10/23/20 2:45 PM, Aleksandra Fedorova wrote:
> Sorry, but you just need to accept the fact that some _early
> development_ work in Fedora ca
On 13/10/20 16:04 +0200, Zdenek Dohnal wrote:
On 10/13/20 12:34 PM, Jonathan Wakely wrote:
On 13/10/20 07:45 +0200, Zdenek Dohnal wrote:
On 10/12/20 5:15 PM, Joe Doss wrote:
On 10/12/20 1:50 AM, Zdenek Dohnal wrote:
This would break using Vim when vim-minimal and vim-enhanced are
installed
On 13/10/20 07:38 -0500, Chris Adams wrote:
Once upon a time, Jonathan Wakely said:
Could vim-minimal and vim-enhanced both install the same
/etc/profile.d/vim.sh file that did something like this?
if [ -n "${BASH_VERSION-}" -o -n "${KSH_VERSION-}" -o -n "${ZSH_VERSI
On 13/10/20 10:53 +0200, Zdenek Dohnal wrote:
On 10/12/20 9:34 PM, clime wrote:
On Mon, 12 Oct 2020 at 07:39, Zdenek Dohnal wrote:
On 10/10/20 2:37 PM, clime wrote:
Hello,
could Fedora and CentOS containers for docker and podman come with
`alias vim=vi` in ~/.bashrc?
I would very much welco
On 13/10/20 07:45 +0200, Zdenek Dohnal wrote:
On 10/12/20 5:15 PM, Joe Doss wrote:
On 10/12/20 1:50 AM, Zdenek Dohnal wrote:
This would break using Vim when vim-minimal and vim-enhanced are
installed (it would start Vi instead of typed Vim). To make it work,
vim-minimal would have to conflict
On 06/08/20 11:34 -0400, John Florian wrote:
I understand better now my problems with my mappings. Above, I said I
had a mapping for :nohlsearch. In actuality, this was ^E
:nohlsearch. Both should work but only the latter now only works
with vim; gvim shows the mapping with :map but I can'
On 05/08/20 04:35 +0200, J. Scheurich wrote:
Am 05.08.20 um 01:52 schrieb Ben Cotton:
Here are some upcoming deadlines and milestones for the Fedora 33
development cycle:
Are you sure, that boost1.73 should be part of fedora 33 ?
It lloks like boost.173 would require a future verson of gcc/g+
On 04/08/20 10:59 -0500, Richard Shaw wrote:
On Tue, Aug 4, 2020 at 10:49 AM Jonathan Wakely
wrote:
On 03/08/20 13:32 -0500, Richard Shaw wrote:
>I finally ran into another issue and used the vim faq. It was ":set
>cindent" that was causing the crazy indentation in spec file %
On 04/08/20 17:48 +0200, Fabio Valentini wrote:
On Tue, Aug 4, 2020 at 5:46 PM Jonathan Wakely
wrote:
On 03/08/20 19:29 +0200, Fabio Valentini wrote:
>On Mon, Aug 3, 2020 at 6:59 PM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 8/3/20 5:53 PM, Kevin Fenzi wrote:
>>
On 03/08/20 13:32 -0500, Richard Shaw wrote:
I finally ran into another issue and used the vim faq. It was ":set
cindent" that was causing the crazy indentation in spec file %changelogs.
I still consider this a bug as the file doesn't even end in c, cpp, cxx,
c++ etc.
What's turning it on for
On 03/08/20 19:29 +0200, Fabio Valentini wrote:
On Mon, Aug 3, 2020 at 6:59 PM Hans de Goede wrote:
Hi,
On 8/3/20 5:53 PM, Kevin Fenzi wrote:
> On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>>
>> I just noticed that a lot my packages got a FTBFS because of
>> f
On 03/08/20 18:03 +0200, Hans de Goede wrote:
Hi,
On 8/3/20 5:53 PM, Kevin Fenzi wrote:
On Mon, Aug 03, 2020 at 05:21:58PM +0200, Hans de Goede wrote:
Hi All,
I just noticed that a lot my packages got a FTBFS because of
failing to build on s390x. The first set of rebuilds failed with:
"Buil
On 03/08/20 17:16 +0200, Andrea Musuruane wrote:
Hi guys,
at least one of the packages I maintain was also affected. Fedora
I'm seeing the same error for boost on both s390x and armv7hl.
Release Engineering has opened a bug against the package for this issue.
Can you please avoid that? Mor
On 28/07/20 22:46 +0200, Andy Mender wrote:
Dear Fedorians,
I really need some help with a review of a GCC toolchain variant I've
started recently: https://bugzilla.redhat.com/show_bug.cgi?id=1350884
A Koji build of the most recent SRPM:
https://koji.fedoraproject.org/koji/taskinfo?taskID=48035
I don't know what part of the procedure you're unclear about, so here's a
summary of the entire process from start to finish.
Get the package sources:
fedpkg clone fctxpd
cd fctxpd
Now download the new upstream code.
Optionally verify the package was downloaded correctly by checking a SHA
or ot
On 29/07/20 10:23 +0200, Florian Weimer wrote:
* Jonathan Wakely:
It's not about devtoolset. Installing CentOS 7 RPMs on Fedora rawhide
is outlandish. It won't work in general, because the CentOS RPMs have
dependencies on CentOS packages, and Fedora has different versions.
Steven h
On 28/07/20 15:05 +0530, Muneendra Kumar M via devel wrote:
Hi All,
I want to upgrade the fctxpd fedora package with additional features.
Iam the maintainer of this fctxpd package in fedora.
Can anyone help me the procedure regarding the same.
I don't know what part of the procedure you're
On 21/07/20 17:12 -0500, Steven Munroe wrote:
Dave Love; writes:
...
I'm pretty sure I said to do that a while ago, like I did when
testing the trivial patch that I didn't expect to cause such trouble.
You probably did say so ;)
I come from a different culture and experience. I am not as conv
On 21/07/20 19:12 +0100, Dave Love wrote:
Jonathan Wakely writes:
On 20/07/20 16:01 -0500, Steven Munroe wrote:
Jonathan Wakely wrote:
Why are you asking fedpkg to build for f33 if you are trying to
package something for el7 and el8?
I am trying to get better turn around for myself as I
On 21/07/20 00:00 +0200, Kevin Kofler wrote:
Steven Munroe wrote:
$ sudo dnf install devtoolset-9-gcc-9.3.1-2.el7.ppc64le.rpm
devtoolset-9-gcc-c++-9.3.1-2.el7.ppc64le.rpm
devtoolset-9-runtime-9.1-0.el7.ppc64le.rpm
devtoolset-9-libstdc++-devel-9.3.1-2.el7.ppc64le.rpm
Installing individual RPMs
On 20/07/20 16:01 -0500, Steven Munroe wrote:
Jonathan Wakely wrote:
Why are you asking fedpkg to build for f33 if you are trying to
package something for el7 and el8?
I am trying to get better turn around for myself as I have local
access to a POWER8 machine. And I was having difficulty
On 20/07/20 13:09 -0500, Steven Munroe wrote:
Then I would have to learn what a "EL7 mock chroot" is. And how it is
man mock
different from "rpmbuild "
That builds the package on your local system, using the packages
available on your local system. If that's Fedora, then you're not
going to
On 20/07/20 17:08 +0100, Jonathan Wakely wrote:
On 20/07/20 10:54 -0500, Steven Munroe wrote:
That looks like a more complete list. Still having problems with dependencies:
$ sudo dnf install devtoolset-9-gcc-9.3.1-2.el7.ppc64le.rpm
devtoolset-9-gcc-c++-9.3.1-2.el7.ppc64le.rpm
devtoolset-9
101 - 200 of 622 matches
Mail list logo
