On Fri, Feb 13, 2015 at 11:55:02AM +, Andrew Haley wrote:
> On 01/24/2015 07:14 PM, Kevin Kofler wrote:
> > Ralf Corsepius wrote:
> >> This is not entirely true. GCC and related projects apply a pretty
> >> complex peer review process, with defined roles and privileges. (Cf. the
> >> file MAINT
On Fri, Feb 13, 2015 at 01:53:12PM -0700, Kevin Fenzi wrote:
> On Fri, 13 Feb 2015 12:47:07 -0800
> Susi Lehtola wrote:
> > as has happened many times before, the GCC bump in rawhide has broken
> > all Fortran packages, desperately needing a mass rebuild.
>
> Can you expand on the breakage? Is i
On Sat, Feb 14, 2015 at 09:25:50AM -0700, Dave Johansen wrote:
> I'm working on packaging include-what-you-use and it works just fine with
> Fedora 21, but in rawhide the tests are failing with std::length_error
> exceptions ( http://koji.fedoraproject.org/koji/taskinfo?taskID=8936112 ).
> I was th
On Sat, Feb 14, 2015 at 11:38:13AM -0700, Dave Johansen wrote:
> On Sat, Feb 14, 2015 at 11:33 AM, Jakub Jelinek wrote:
>
> > On Sat, Feb 14, 2015 at 09:25:50AM -0700, Dave Johansen wrote:
> > > I'm working on packaging include-what-you-use and it works just fine wi
On Sun, Feb 15, 2015 at 11:08:55PM +0100, Michael Schwendt wrote:
> On Sun, 8 Feb 2015 18:17:56 +0100, Marek Polacek wrote:
>
> > either package bugs, or GCC bugs. As things stand, just about 19 packages
> > did
> > not build due to bugs in gcc-5.0.0-0.5.fc22. All GCC bugs except one are
> > f
On Mon, Feb 16, 2015 at 08:33:48AM -0700, Orion Poplawski wrote:
> Trying to build cmake, getting:
In F23, all C++ packages need to be rebuilt, most likely you have a
dependency, that hasn't been rebuilt yet (libjsoncpp)?
So talk to the maintainer to rebuild it first.
Jakub
--
devel mail
On Mon, Feb 16, 2015 at 11:35:17AM -0700, Kevin Fenzi wrote:
> FESCo decided to not do a mass rebuild for f22, but gcc-5 (with a
> change to config from f23) was approved to land in f22.
>
> > - A GCC-5 has been pushed to rawhide and already _is_ being used to
> > build packages and causing all
On Tue, Feb 17, 2015 at 08:45:09AM +, Andrew Haley wrote:
> On 17/02/15 07:21, David Airlie wrote:
>
> > Well I can't provide any info, I don't have an ARM box here, and it
> > happens in the buildroot which I don't think I can access to get the
> > files out from.
>
> I've been bitten by thi
On Tue, Feb 17, 2015 at 11:18:54AM +, Peter Robinson wrote:
> Please file a bug and mark it a blocker to ARMTracker bug. It might be
> similar to some of the other ARM ICEs we're getting but I'd sooner
> have a dupe than miss a bug. Put the details of the koji tasks in the
> BZ and we can eithe
On Thu, Feb 19, 2015 at 09:14:32AM +, Richard W.M. Jones wrote:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1194167
>
> Basically everything in Rawhide which uses the normal RPM
> opt flags will now have to be compiled with -fPIC, otherwise
> you get errors like:
>
> /usr/bin/ld: /tmp/cc
On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> explicitly in the real program. It's being added to everything by
> something in RPM. I'm not exactly sure what, maybe %{configure}?
>
> So I don't k
On Thu, Feb 19, 2015 at 09:51:33AM +, Richard W.M. Jones wrote:
> There is definitely new/different behaviour in Rawhide, and recently.
>
> Also I was only able to see the new behaviour by updating from gcc 4.x
> -> gcc 5. ie. Updating redhat-rpm-config isn't what causes the
> problem.
Well,
On Thu, Feb 19, 2015 at 10:11:07AM +, Richard W.M. Jones wrote:
>
> I'm still no closer to being able to fix the problem.
>
> I have to add -fPIE (or is that -pie or -fpie or -DPIE) to every
> executable? Upstream? Will that break on some platforms/architectures?
It really should be just a
On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> info gcc, of course yes. -DPIC is not documented at all, and the
> various pie/pic options are obscure to say the least.
Why should -DPIC be documented? -D is documented. -DPIC means define
macro PIC to 1. There is no magic
On Thu, Feb 19, 2015 at 10:37:46AM +, Richard W.M. Jones wrote:
> On Thu, Feb 19, 2015 at 11:35:17AM +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 10:30:50AM +, Richard W.M. Jones wrote:
> > > info gcc, of course yes. -DPIC is not documented at all, and the
>
On Thu, Feb 19, 2015 at 04:12:43PM +0100, Frantisek Kluknavsky wrote:
> a list of things that usually break with each new gcc (like fortran modules)
> would be nice to avoid a lot of pain with debugging. Does it already exist?
>
> WxGTK keeps a string WX_BUILD_OPTIONS_SIGNATURE currently saying "2
On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote:
> On Thu, Feb 19, 2015 at 10:42:02AM +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 09:37:16AM +, Richard W.M. Jones wrote:
> > > The thing is, I'm not adding -specs=/usr/lib/rpm/redhat/redhat-hardened
On Thu, Feb 19, 2015 at 01:02:29PM -0500, Adam Jackson wrote:
> On Thu, 2015-02-19 at 18:05 +0100, Jakub Jelinek wrote:
> > On Thu, Feb 19, 2015 at 06:00:41PM +0100, Till Maas wrote:
> > > I plan to change this to 1 now in Rawhide for the upcoming Fedora 23
> >
On Thu, Feb 19, 2015 at 07:48:30PM +0100, Till Maas wrote:
> On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
>
> > Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
> > it, now in F22+ we might have smaller slowdown with t
On Thu, Feb 19, 2015 at 07:58:10PM +0100, Reindl Harald wrote:
>
> Am 19.02.2015 um 19:48 schrieb Till Maas:
> >On Thu, Feb 19, 2015 at 07:07:45PM +0100, Jakub Jelinek wrote:
> >
> >>Even on x86_64 it was quite a measurable slowdown last time I've benchmarked
&
On Tue, Feb 07, 2017 at 11:59:33PM +, Tom Hughes wrote:
> On 07/02/17 23:56, Stephen John Smoogen wrote:
> > On 7 February 2017 at 18:39, Sérgio Basto wrote:
> > > Hi,
> > > On Ter, 2017-02-07 at 22:32 +0100, Marek Polacek wrote:
> > > > some C++ FE changes (especially the "Fix type-dependence
On Wed, Feb 08, 2017 at 01:11:32PM +0100, Marek Skalický wrote:
> Marek Polacek píše v Út 07. 02. 2017 v 22:32 +0100:
> > It's been a tradition now that every January we rebuild all the
> > Fedora packages
> > with the upcoming GCC, to reveal as many bugs as possible before we
> > release
> > the n
On Mon, Feb 13, 2017 at 08:39:00PM +0100, Francisco J. Tsao Santin wrote:
> Hi all,
>
> We have a problem with the hardlink package. The koji build made by Fedora
> Release Engineering failed in armv7hl and i686 architectures. I saw the logs
> and I tried a mock build in my own machine too, the pr
On Tue, Feb 14, 2017 at 11:23:43PM +0100, Jakub Jelinek wrote:
> GNU89 vs. C99 inlining, that code is really old and apparently nobody
> touched it since it has been written.
>
> As everything is in a single file, either change all the inlines in the file
> to static inline, or
On Wed, Feb 15, 2017 at 04:33:19PM -0500, Stephen John Smoogen wrote:
> On 14 February 2017 at 17:23, Jakub Jelinek wrote:
> > On Mon, Feb 13, 2017 at 08:39:00PM +0100, Francisco J. Tsao Santin wrote:
> >> Hi all,
> >>
> >> We have a problem with the hard
On Mon, Feb 20, 2017 at 09:15:46AM +0100, Jan Synacek wrote:
> Hi,
>
> warzone2100 fails to build [1] and I have no idea how to fix that.
> Most of the errors are:
>
> main_sdl.cpp:79:13: error: expected unqualified-id before '__attribute__'
> static std::vector displaylist; // holds all our pos
Hi!
As you might know, redhat-rpm-config is adding -Wall -Werror=format-security
into $RPM_OPT_FLAGS/%{optflags} by default.
I've recently fixed a bug #1425825 where -Wall -Werror=format-security -Wall
or -Wall -Werror=format-security -Wformat etc. actually disabled the
-Wformat-security warning (
On Sun, Mar 19, 2017 at 07:30:24PM +0100, Kevin Kofler wrote:
> That was not a new issue in GCC 7, it is how -Werror=format-security had
> behaved since its introduction. It is just that the behavior change in GCC 7
> came in late, after the mass rebuild had already happened.
>
> For what it's w
On Wed, Mar 22, 2017 at 08:48:42PM -0700, Luya Tshimbalanga wrote:
> I just hit an issue when scratch building embree on either rawhide and F26:
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=18532546
>
> Does anyone encounter similar problem?
This is a bug in the spec file, the options
Hi!
A severe ABI bug on AArch64 and especially on ARM 32-bit has been
recently discovered and GCC 7.1 is going to have that ABI change in.
For details see http://gcc.gnu.org/PR77728
gcc-7.1.1-0.16.fc{26,27} which I'll build tomorrow will contain the
ABI changes as well as a -Wpsabi diagnostics (no
On Tue, Apr 25, 2017 at 07:37:03PM +0100, Peter Robinson wrote:
> On Tue, Apr 25, 2017 at 4:52 PM, Jakub Jelinek wrote:
> > A severe ABI bug on AArch64 and especially on ARM 32-bit has been
> > recently discovered and GCC 7.1 is going to have that ABI change in.
> >
On Fri, May 05, 2017 at 04:18:47PM +0200, Marek Polacek wrote:
> I've started our own mass rebuild. To whittle down the list of packages
> to rebuild, I chose to only build C++ packages. This I did by looking
> at *.debug files, DW_AT_producer in particular.
>
> The aarch64 rebuild is done, and
On Fri, May 12, 2017 at 05:13:04PM -0700, Adam Williamson wrote:
> Hi folks! The Fedora 26 Beta freeze is fast approaching (it's 2017-05-
> 16), so it's time for a blocker status mail.
I think
https://pagure.io/releng/issue/6781
is a beta blocker too.
Jakub
___
On Mon, May 22, 2017 at 05:22:48PM +0200, Mattia Verga wrote:
> https://github.com/OpenPHDGuiding/phd2/issues/608
>
> I'm getting ctest failure only on F26 (and rawhide) i386, while on F25 all
> it's working fine.
> Can a precision problem be introduced in Eigen3 with the passage from GCC6
> to GC
On Tue, Jul 11, 2017 at 09:36:28PM -0400, Carlos O'Donell wrote:
> On 07/06/2017 09:15 PM, Matthew Miller wrote:
> > https://fedoraproject.org/wiki/Releases/28/Schedule
>
> I encourage Jeff Law and Jakub Jelinek to review these schedules
> for compiler related issu
On Wed, Jul 12, 2017 at 04:45:56PM -0400, Matthew Miller wrote:
> On Wed, Jul 12, 2017 at 04:30:12PM -0400, Matthew Miller wrote:
> > So, "one week earlier than last time" would be January 31st. (Or 30th?
> > Depends if we want that on a Tuesday like everything else or Wednesday
> > like this time
On Wed, Dec 04, 2013 at 05:11:16PM -0600, Ian Pilcher wrote:
> On 12/04/2013 04:56 PM, Brendan Jones wrote:
> > Patching is not a problem. Unnecessary is the question. Explain to me
> > (not you in particular Rahul) how these printf's can possibly be exploited?
>
> char *output;
>
> output =
On Fri, Dec 06, 2013 at 08:02:06PM +0100, Kevin Kofler wrote:
> * translatable format strings, e.g.
> printf(translate("processed %d items"), foo);
Translatable strings are handled just fine.
Try e.g.:
extern int my_printf (void *my_object, const char *my_format, ...)
__attribute__ ((format (
On Mon, Dec 09, 2013 at 03:01:55PM -0800, Les Howell wrote:
> unless something has changed recently fputs and puts just like gets and
> fgets have been deprecated and are discouraged due to potential security
> issues.
That is wrong. Only gets is deprecated (removed in C11, obsolescent in
POSIX
On Wed, Dec 11, 2013 at 05:42:16PM +0100, Reindl Harald wrote:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=483733
>
> [root@testserver:~]$ rpm -qa | grep gcc
> gcc-c++-4.8.2-5.fc19.x86_64
> libgcc-4.8.2-5.fc19.x86_64
> gcc-4.8.2-5.fc19.x86_64
>
> are these packages are missing on bodhi
On Thu, Feb 04, 2016 at 01:36:50PM +0100, Sandro Mani wrote:
> Med builds are failing with
>
> medfile_int_wrap.cc:11272:30: error: no matching function for call to
> 'std::vector
> >::erase(SwigValueWrapper<__gnu_cxx::__normal_iterator std::vector > > >&)'
>result = (arg1)->erase(arg2);
>
On Wed, Feb 10, 2016 at 05:27:46PM +0100, Tomáš Smetana wrote:
> Hello,
> one of my packages (tvtime) failed to build during the mass rebuild. Not a
> big deal, I think there are several ways to fix it. The odd thing is that the
> build failed due to a rather unexpected change in C++ preprocessor
On Mon, Feb 15, 2016 at 04:46:32PM +0100, Dan Horák wrote:
> On Mon, 15 Feb 2016 09:35:03 -0600
> Richard Shaw wrote:
>
> > On Mon, Feb 15, 2016 at 8:50 AM, Dan Horák wrote:
> >
> > > On Mon, 15 Feb 2016 08:34:31 -0600
> > > Richard Shaw wrote:
> > >
> > > > Can someone point me in the right d
On Wed, Feb 17, 2016 at 05:43:51PM +0100, Petr Spacek wrote:
> __attribute__((nonnull)) is tremendously useful for static code analysis and
> helped to uncover a lot of (not-yet triggered) issues in the code, so just
> removing the attribute would not make me happy.
Sure.
> On the other hand, ass
On Wed, Feb 17, 2016 at 11:14:29AM -0600, Michael Catanzaro wrote:
> El mié, 17-02-2016 a las 17:53 +0100, Jakub Jelinek escribió:
> > That is wrong. Even older gcc versions would just optimize away the
> > assertion.
>
> Even in -O0 builds?
Probably not, though the warni
On Wed, Feb 17, 2016 at 05:30:27PM +, Daniel P. Berrange wrote:
> Instead of using __attribute__((nonnull)) directly in the code, define a
> macro for it. When compiling normal builds with gcc, make the macro
> expand to nothing, but when compiling with coverity or other static analysis
> tools
On Fri, Feb 19, 2016 at 03:12:29AM +0100, Kevin Kofler wrote:
> Jakub Jelinek wrote:
> > ASSERT(this) is pointless, it is testing if undefined behavior didn't
> > happen after the fact, that is just too late. As I said, use
> > -fsanitize=undefined to make sure you don
On Fri, Feb 19, 2016 at 01:44:45PM +0100, Petr Spacek wrote:
> > It's about checking whether "this", in C++, is NULL. Since any call on a
> > null
> > pointer is undefined behavior, any code relying on such checks is
> > non-standard.
>
> Ah, okay. I was talking about pure C all the time, so I
On Mon, Feb 22, 2016 at 08:35:34AM -0700, Jerry James wrote:
> I don't think this has been fixed. I updated ntl over the weekend,
> and rebuilt Macaulay2 as part of that work. Macaulay2 still failed
> with this same error, using gcc-6.0.0-0.11.fc24, so I added a patch to
> workaround the issue, s
On Sat, Feb 27, 2016 at 11:03:57PM +0100, Hans de Goede wrote:
> I'm having this weird issue in rawhide / f24 where I get the following
> error:
>
> ldd -r /usr/lib64/libsfml-graphics.so
>
>
>
> undefined symbol: __cpu_model (/usr/lib64/libsfml-graphics.so)
How do you link the shared library
On Sat, Feb 27, 2016 at 11:18:35PM +0100, Hans de Goede wrote:
> On 27-02-16 23:08, Jakub Jelinek wrote:
> >On Sat, Feb 27, 2016 at 11:03:57PM +0100, Hans de Goede wrote:
> >>I'm having this weird issue in rawhide / f24 where I get the following
> >>error:
&g
On Sun, Feb 28, 2016 at 09:56:24PM +, Tom Hughes wrote:
> From past experience I know that they haven't shown a huge amount of
> interest in failures that are specific to 32 bit platforms though in this
> case they do have somebody that has been trying to tame some of the wilder
> excesses of m
On Sat, Mar 05, 2016 at 04:09:55PM +0200, Ville Skyttä wrote:
> Rawhide repos have currently compat-gcc-296 and compat-gcc-32 -debuginfo
> and source packages but the corresponding main binary packages are not
> there. Shouldn't all or none of them be there, something wrong with the
> compose?
com
On Wed, Apr 13, 2016 at 10:56:35PM +0200, Michael Schwendt wrote:
> audacious-plugins-3.7.2 in Rawhide koji failed to build with constexpr
> errors in various plugins.
>
> What exactly has changed?
>
>
> https://kojipkgs.fedoraproject.org//work/tasks/5212/13645212/build.log
>
> metronom.cc:50:3
On Mon, May 02, 2016 at 10:03:51AM -0600, Chris Murphy wrote:
> On Mon, May 2, 2016 at 8:58 AM, Dominik 'Rathann' Mierzejewski
> wrote:
> > On Monday, 02 May 2016 at 15:24, Stephen Gallagher wrote:
> > [...]
> >> All of the major stakeholders that usually trigger a mass rebuild (GCC,
> >> glibc,
On Tue, Dec 06, 2016 at 02:51:14PM -, Jeremy Newton wrote:
> Anyone have any idea what causes these errors? Trying to update a package and
> it failed during a local test build in mock (f25):
>
> In file included from /usr/include/c++/6.2.1/stdlib.h:36:0,
> from expr.ypp:5:
>
On Tue, Dec 06, 2016 at 08:41:46PM +0100, Florian Weimer wrote:
> On 12/06/2016 08:36 PM, James Hogarth wrote:
> >On 6 December 2016 at 19:24, Adam Williamson
> >wrote:
> >>So, https://bugzilla.redhat.com/show_bug.cgi?id=1401231 seems to be
> >>basically breaking everything in Rawhide at present.
On Wed, Dec 07, 2016 at 11:04:37AM +0100, Stephan Bergmann wrote:
> On 12/06/2016 04:16 PM, Jakub Jelinek wrote:
> >On Tue, Dec 06, 2016 at 02:51:14PM -, Jeremy Newton wrote:
> >>Anyone have any idea what causes these errors? Trying to update a package
> >>and it
On Sat, Dec 17, 2016 at 04:03:22PM +0100, Sandro Mani wrote:
> Hi
>
> I'm having some difficulties understanding the following error on ppc64le
> (scratch build [1], build log [2]):
>
> PackMath.h:
>
> 191 template<> inline v4f ei_pset1(const float& from)
> 192 {
> 193// Taken from
> http
On Mon, Dec 19, 2016 at 05:12:25PM +0100, Florian Weimer wrote:
> On 12/19/2016 05:00 PM, Neal Gompa wrote:
> > Hello,
> >
> > I just imported lugaru and attempted to build it for rawhide, but it
> > failed in such a strange way on ppc64le, with errors saying it can't
> > convert bool to vectorize
On Mon, Dec 19, 2016 at 01:20:14PM -0500, Neal Gompa wrote:
> >> The most common source is from GCC.
> >
> > These days (for several GCC releases), powerpc as well as spu and recently
> > also s390 (z13) use conditional macros for bool, vector, pixel and _Bool,
> > which expand differently dependi
On Mon, Jan 02, 2017 at 02:29:47PM +0100, Florian Weimer wrote:
> We received a bug report that generated RPM dependencies are too coarse in
> rawhide (#1409557).
>
> The bug report is correct at a technical level. But I assumed that it was
> not a problem because partial upgrades are in rawhide
On Tue, Jan 03, 2017 at 08:08:32AM -, Lukas Slebodnik wrote:
> > On Mon, 2017-01-02 at 20:43 -0800, Adam Williamson wrote:
> >
> > ...but to expand on that, that's for stable releases. So far as Rawhide
> > is concerned, historically my understanding has been the same as
> > Florian's, we have
On Thu, Jan 05, 2017 at 03:08:21PM -0800, Brendan Conoboy wrote:
> On 01/05/2017 02:08 PM, Stephen Gallagher wrote:
> [snip]
> > == multi-arch layout ==
> > * Moving the locations of all of the system libraries would potentially
> > still
> > break third-party applications that were compiled to ex
On Sat, Jan 07, 2017 at 11:15:28PM +, Richard W.M. Jones wrote:
> On Fri, Jan 06, 2017 at 02:47:35AM +0100, Pavel Raiskup wrote:
> > On Thursday, January 5, 2017 5:08:16 PM CET Stephen Gallagher wrote:
> > > Two suggestions were raised as alternatives to the container approach:
> > >
> > > * S
On Wed, Jan 11, 2017 at 04:17:56AM +, Richard W.M. Jones wrote:
> On Tue, Jan 10, 2017 at 10:28:37AM +0100, Jan Kurik wrote:
> > * Other developers:
> > First few days/weeks just voluntary rebuilds using the new system gcc,
> > if things fail, look at http://gcc.gnu.org/gcc-7/porting_to.html an
On Fri, Feb 03, 2017 at 02:51:28PM +, Daniel P. Berrange wrote:
> On Fri, Feb 03, 2017 at 02:45:08PM +, David Howells wrote:
> > Hi,
> >
> > gcc and cross-gcc currently dynamically load the isl-0.14 shared library -
> > which means that rpm-build doesn't automagically detect a:
> >
> >
On Thu, Mar 26, 2020 at 07:52:37AM -0500, Rex Dieter wrote:
> Heads up in case anyone else hits this since apparently new gcc landed in
> rawhide last night (gcc-10.0.1-0.10.fc33)
>
> Been working on/off for almost 2 weeks to get latest qtwebengine to build
> (and finally got all scratch builds
On Mon, Mar 30, 2020 at 11:34:15AM -0600, Nathanael D. Noblet wrote:
> I have a project that isn't part of Fedora yet - though really I
> should add it at this point. Its php-cpp. It allows me to write c++
> extensions for PHP. Its worked well for a couple years. I upgraded to
> F32 beta and now
On Mon, Mar 30, 2020 at 07:50:48PM +0200, Jakub Jelinek wrote:
> On Mon, Mar 30, 2020 at 11:34:15AM -0600, Nathanael D. Noblet wrote:
> > I have a project that isn't part of Fedora yet - though really I
> > should add it at this point. Its php-cpp. It allows me to write c+
On Fri, Apr 03, 2020 at 07:36:34PM +0200, Florian Weimer wrote:
> * Neal Gompa:
>
> > Maybe this is a dumb question, but why do we not want to ship this? I
> > can't seem to figure out why we keep trying to block it, what harm it
> > causes to ship it, and so on...
>
> We haven't been able to shi
On Sat, May 02, 2020 at 12:36:29PM +0200, Sandro Mani wrote:
> Hi
>
> I'm stuck on the following build failure of the aarch64 build here [1]
>
> /usr/bin/ld: .libs/geod: hidden symbol `__aarch64_ldadd4_acq_rel' in
> /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced by
> DSO
On Mon, May 04, 2020 at 11:35:42AM +0200, Miro Hrončok wrote:
> On 04. 05. 20 7:59, Milan Crha wrote:
> > Hi,
> > out of the interest (no offense meant), would this not be caught by the
> > rawhide gating? I'd expect that this is something what the rawhide
> > gating would avoid. Of course, it
On Tue, May 05, 2020 at 11:58:11AM +0200, Stephan Bergmann wrote:
> So when is doing koji f32 aarch64 builds expected to work again? (Asking
> because a flatpak build of mine was still failing because of this issue a
> couple of hours ago, and I'm not sure this is generally not expected to work
> a
On Fri, May 08, 2020 at 11:54:07AM +0200, Sandro Mani wrote:
> Hi
>
> I'm hitting the following error (and other similar ones) with this
> qt-creator build [1] on armv7hl and armv7hl only:
Code snippets like that aren't useful for analyzing what's going on, as they
can't be compiled. Please send
On Tue, May 19, 2020 at 11:58:47AM +0200, Vitaly Zaitsev via devel wrote:
> On 19.05.2020 11:40, Fabio Valentini wrote:
> > As I wrote in my direct response to Guido, doing a mass rebuild for
> > fedora just isn't possible in released branches. So, the best we can
> > do is to deal with issues as p
On Tue, Oct 08, 2019 at 06:42:40PM +0100, Tomasz Kłoczko wrote:
> To be honest IMO separating aspell dictionaries is a bit illogical because
> on distribution layer language dependent resources should be described by
> %lang() and chosen on install stage by %_install_langs.
> Ergo: all "langpack" (
On Wed, Nov 06, 2019 at 12:12:54PM +0100, Jan Kratochvil wrote:
> On Wed, 06 Nov 2019 11:49:18 +0100, Vít Ondruch wrote:
> > > we can achieve a
> > > performance gain of 5% to 27% depending on the workload.
> >
> > Where are these number coming from? And what is the reason for the
> > performance
On Wed, Dec 11, 2019 at 02:53:22PM +0100, Miro Hrončok wrote:
> Hello,
>
> what are the gcc 10 plans for Fedora 32? Will there be a change proposal for
> that? Is Fedora 32 the target for gcc 10?
Yes.
> I remember that gcc was updated to 9 during Fedora 30 cycle without a change
> proposal and t
On Tue, Dec 31, 2019 at 02:03:23PM +0900, Mamoru TASAKA wrote:
> Hello, all:
>
> So I again looked at
> https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html
> and proposal submission deadline for changes requiring mass rebuild is due
> today
> (2019/12/31). If I am correct we have n
On Tue, Jan 21, 2020 at 01:42:25PM +0100, Fabio Valentini wrote:
> I've seen this issue pop up in some other packages, as well.
>
> My elementary-files package is affected, and I think it broke
> rubygem-ffi, too (which is blocking the ruby 2.7 rebuild, breaking a
> lot of ruby packages; though I
On Tue, Jan 21, 2020 at 01:16:30PM -0700, Jeff Law wrote:
> Starting with gcc-10, these are now fatal errors which look something
> like this:
>
>
>
> Error: Rank mismatch in argument ‘array’ at (1) (rank-1 and scalar)
Indeed, and https://gcc.gnu.org/gcc-10/porting_to.html#argument-mismatch
tal
On Thu, Jan 23, 2020 at 04:48:14PM +0100, Robert-André Mauchin wrote:
> How to fix the affected packages? For some I ised extern and it worked but
> for
> other using extern resulted in error like:
>
> /usr/bin/ld: /builddir/build/BUILD/uTox-0.17.1/src/xlib/main.c:590: undefined
> reference to
On Mon, Jan 27, 2020 at 10:25:50AM -0500, Mohan Boddu wrote:
> Hi all,
>
> Per the Fedora 32 schedule[1] we will be starting a mass rebuild for
> Fedora 32 today. We are doing a mass rebuild for Fedora 32 for all the
> changes:
>
> https://fedoraproject.org/wiki/Changes/GLIBC231
> https://fedorap
On Fri, Jan 31, 2020 at 04:32:15PM +0100, Alejandro Álvarez Ayllón wrote:
> I am on the process of creating a new package, and making sure it builds
> smoothly on Fedora.
> However, even if it compiles successfully in ppc64le, the %check command
> fails with this error:
>
> /builddir/build/BUILDRO
On Wed, Feb 05, 2020 at 05:13:27PM +, Dave Love wrote:
> GCC doesn't document the targets for which -fno-common produces better
> code. Can someone say for which of the Fedora ones it makes a
> difference?
E.g. on any that is capable of vectorization.
Common vars can't have alignment increase
On Thu, Feb 06, 2020 at 11:01:56AM +, Dave Love wrote:
> Jakub Jelinek writes:
>
> > On Wed, Feb 05, 2020 at 05:13:27PM +, Dave Love wrote:
> >> GCC doesn't document the targets for which -fno-common produces better
> >> code. Can someone say for
On Fri, Feb 28, 2020 at 08:27:02AM -0700, Orion Poplawski wrote:
> On 2/28/20 8:20 AM, Vitaly Zaitsev via devel wrote:
> > On 28.02.2020 16:04, Orion Poplawski wrote:
> > > I have already reduced the make parallelism to 1, so not sure what else
> > > I can do to avoid this other than to exclude it
On Mon, Mar 02, 2020 at 08:57:46AM -0500, Tom Callaway wrote:
> Wait, I know that $TOPIC is scary, come back.
>
> Chromium has this chunk of code (in
> third_party/angle/src/common/PackedEnums.h):
>
> // This horrible const_cast pattern is necessary to work
> around a constexpr limit
On Mon, Mar 02, 2020 at 08:57:46AM -0500, Tom Callaway wrote:
> Wait, I know that $TOPIC is scary, come back.
>
> Chromium has this chunk of code (in
> third_party/angle/src/common/PackedEnums.h):
>
> // This horrible const_cast pattern is necessary to work
> around a constexpr limit
On Sat, Mar 14, 2020 at 11:54:54PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> > Known issue?
>
> The above was with gcc-10.0.1-0.9.fc32 and annobin-9.06-1.fc32.
>
> Looks like it was fixed in the meantime as another build gets
> gcc-10.0.1-0.8.fc32 and the same annobin now.
One either needs
On Fri, Jan 11, 2019 at 01:11:00PM +0100, Tomasz Kłoczko wrote:
> On Fri, 11 Jan 2019 at 05:27, Jens-Ulrik Petersen
> wrote:
> [..]
>
> > %find_lang used --with-man option takes care of collecting all language
> >> specific man pages as well, and more than 100 Fedora package are using this
> >> o
On Mon, Jan 21, 2019 at 03:11:24PM +0300, Vascom wrote:
> Why package gcc has version 9.0.0 but in changelog - 9.0.1?
Fixed in my copy. 9.0.0 is the right version.
Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe sen
On Mon, Jan 21, 2019 at 10:36:51PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> I certainly would be very disappointed to not see the latest release
> of gcc in Fedora. The release notes are underwhelming, but I expect
> there are many improvements to look forward to. For example, I know
> there are
On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote:
> This is already happening, gcc was updated, I see bugs for gcc 9 related
> FTBFS being open. This is not a proper way to coordinate this kind of thing.
I'm sorry, I forgot to create the every year feature request for GCC this
year and
On Tue, Jan 29, 2019 at 07:07:02AM -0500, Siteshwar Vashisht wrote:
>
>
> - Original Message -
> > From: "Jakub Jelinek"
> > To: "Development discussions related to Fedora"
> >
> > Sent: Monday, January 21, 2019 10:51:32 PM
> >
On Tue, Jan 29, 2019 at 12:51:25PM +, Daniel P. Berrangé wrote:
> Libvirt has hit a problem with -Wjump-misses-init newly reporting bogus
> warnings for code using anonymous struct initializers during assignments:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061
> https://bugzilla.re
On Tue, Jan 29, 2019 at 01:04:25PM +, Daniel P. Berrangé wrote:
> The variable was already initialized right at the start. The compound
> literal is just a short-hand for later changing the values in several
> fields of the struct at once. This is no different to manually assigning
> new values
On Sat, Feb 02, 2019 at 08:57:42AM -, Samuel Rakitničan wrote:
> With a new version of GCC errors are blocking the build at various places.
> Not sure how serious the issue is. Should I just add the compiler flags
> to get through the build?
Guess the important question is, is the warning co
On Thu, Feb 07, 2019 at 10:08:26AM -, Martin Gansser wrote:
> Hi,
>
> the compilation of mellowplayer-3.5.1 with gcc-9.0.1 fails on Fedora 30, see
> the build.log [1]
>
> Fedora Bugzilla [2] - -Wredundant-move gives false positives in C++11 mode
>
> [1] https://kojipkgs.fedoraproject.org//w
201 - 300 of 479 matches
Mail list logo
