Hi,
I'm trying to build gource for F-14 and I get the following error:
=
[siddh...@spoyarek gource]$ git branch
* f14
master
[siddh...@spoyarek gource]$ fedpkg build
Created task: 2382335
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2382335
Watching tas
On Thu, Aug 05, 2010 at 08:53:17PM +0200, Michael Schwendt wrote:
> On Fri, 6 Aug 2010 00:17:23 +0530, Siddhesh wrote:
>
> > Hi,
> >
> > I'm trying to build gource for F-14 and I get the following error:
>
> > 2382335 build (dist-f14-updates-candidate,
> > /gource:94e27ff92af9990ba724746702f7e3
Hi,
I have rebased LibRaw in rawhide to 0.14.3. There is now a shared
library with this version, so it is recommended that packages that
were linking against LibRaw statically, now do so dynamically.
--
Siddhesh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/
Hi,
I got a request to include demosaic packs into the LibRaw build to
support some digital cameras:
https://bugzilla.redhat.com/show_bug.cgi?id=760638
With this inclusion, the LibRaw package will have a GPLv3+ license
since the demosaic packs are released under GPLv2+ and
GPLv3+. Currently only
Hi,
I maintain LibRaw, which is only a static library -- upstream has
rejected the idea of maintaining dynamic libs since they would have to
take care of ABI compatibility across releases.
I wanted to know if there are any other only-static libraries out
there and how they maintainers manage rele
On Sat, Nov 13, 2010 at 11:38:50PM +, Michel Alexandre Salim wrote:
> I'd say do try a rebuild of affected packages yourself, and notify the
> maintainers only in case there is a breakage and coordinate on what to do
> (otherwise they'd get an unpleasant FTBFS report).
>
That was helpful, th
On Tue, Dec 07, 2010 at 05:45:58PM +0100, Andreas Tunek wrote:
> How do I reopen the bug? Previously in the bug report I stated that
> this affects F14 as well (not F13), but I can not change the version.
> Do I have to file a new bug?
I have reopened it for you.
--
Siddhesh
--
devel mailing lis
Hi,
The upstream shotwell does not build with vala 0.11.* since there are
a bunch of incompatible changes between vala-0.10.x and 0.11.x. Is
there a plan to have a parallel installable vala-0.10.x in
rawhide/f15?
I can't see any other way to get shotwell built. I tried making
changes to shotwell-
On Wed, Jan 05, 2011 at 07:31:13PM +, Peter Robinson wrote:
> Well as vala generates C code the current version should continue to
> function until shotwell 0.9.x comes out and adds support for the newer
> vala and it can be compiled or a patch appears in head that we can
> apply to 0.8.x
>
>
On Thu, Jan 06, 2011 at 08:03:20AM +0530, Siddhesh Poyarekar wrote:
> On Wed, Jan 05, 2011 at 07:31:13PM +, Peter Robinson wrote:
> > Well as vala generates C code the current version should continue to
> > function until shotwell 0.9.x comes out and adds support for the newer
On Sun, May 23, 2010 at 12:58:32AM +0200, Uwe Kubosch wrote:
>Thank you for your reply. I was able to fix the immediate error by
>linking with libcrypto as suggested.
>Now I get
>
> gcc -o cmd/zdb/zdb -pipe -Wall -s cmd/zdb/zdb.o cmd/zdb/zdb_il.o
> cmd/zdb/ptrace.o lib/libavl/libavl
Hi,
I have packaged LibRaw since it is needed to build Shotwell
trunk. Review Request link here:
https://bugzilla.redhat.com/show_bug.cgi?id=602279
Anyone trying to build Shotwell will need this and gexiv2, which has
also been packaged:
https://bugzilla.redhat.com/show_bug.cgi?id=599097
--
Si
On Thu, Jul 01, 2010 at 01:07:02PM -0400, Toshio Kuratomi wrote:
> libart_l...@fedoraproject.org, liboil-ow...@fedoraproject.org,
> librs...@fedoraproject.org
> Bcc:
> Subject: A few orphaned desktop/graphics packages
> Reply-To:
>
> The following packages related to graphics and the desktop hav
On Wed, Jul 30, 2014 at 03:36:34PM -0400, Matthew Miller wrote:
> > > The changes in the rebase should be minor since we've
> > > been tracking master the whole time.
> > I remember a similar process causing problems in Rawhide earlier and Jared
> > Smith talking with the glibc team to ensure that
On Thu, Jul 31, 2014 at 02:13:44PM +0100, Peter Robinson wrote:
> The fact that a core library that's stability is critical to the
> distribution as a whole doesn't bother to adhere to this and while
> having gone through the hoops of putting in a feature change basically
> then proceeded to comple
On Thu, Jul 31, 2014 at 03:06:00PM +0100, Richard W.M. Jones wrote:
> However the previous problem(s -- multiple) was glibc using
> non-Rawhide for integration testing, especially just while we were
> trying to stablise Fedora for a release:
>
> https://lists.fedoraproject.org/pipermail/devel/2011
On Thu, Jul 31, 2014 at 09:03:45AM -0400, Rahul Sundaram wrote:
> Yes. My concern is that glibc is using Rawhide as their continuous
> integration sandbox to shake out bugs as opposed to doing it elsewhere and
> just taking care of integration of releases when they are ready. If this
> viewed as
On Fri, Sep 26, 2014 at 08:53:59PM +0200, Hans de Goede wrote:
> I've just tested the F-21 update for this, and I'm afraid that the
> problem is still present there. I've also regenerated my initrd to make
> sure that that included the new glibc too, but that did not help.
Do you still see crashes
On Fri, Mar 06, 2015 at 01:34:36PM +, Jonathan Wakely wrote:
> I'm also the author of one package included in Fedora, pstreams-devel,
> so would be happy to help with the packaging for that.
Great, you could apply for co-maintainership:
http://fedoraproject.org/wiki/Package_maintainer_policy#
On Wed, Mar 18, 2015 at 11:53:50AM +, Peter Robinson wrote:
> > In the cloud and docker images, we've been carrying horribly hacks
> > (really, horrible) to strip this out ofter the fact. The new fix would
> > let us get the same effect the right way. I'm told that this is a
> > low-risk change
On Sat, Apr 18, 2015 at 01:49:57PM -0600, Philip Prindeville wrote:
> If you go back through the previous glibc bugs, you'll find:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=984
>
> from 2005 which was closed out as "RESOLVED, WONTFIX" with the text:
>
> There is a solution, already
Hi,
The latest glibc in rawhide (2.21.90-13.fc23) has a new implementation
for pthread condition variable functions (pthread_cond_wait,
pthread_cond_timedwait, etc.). If you experience any weird locking
issues or bugs that can be attributed to pthread_cond_* functions
potentially misbehaving, ple
On Fri, May 22, 2015 at 02:39:11PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 22 May 2015 at 06:57, Siddhesh Poyarekar wrote:
> > Hi,
> >
> > The latest glibc in rawhide (2.21.90-13.fc23) has a new implementation
> > for pthread condition
On Fri, May 22, 2015 at 06:21:43PM +0530, Siddhesh Poyarekar wrote:
> No, these are different. This problem was introduced in
> 2.21.90-7.fc23. The actual bug is much older and was hidden and only
Of course, I meant 2.21.90-8.fc23. It worked correctly on 2.21.90-7.
Si
Hi,
I took eog over when it was orphaned last time, since I though I could
work on it some more. I never got around to anything but a couple of
bug reports though and I don't think I'm really going to get around to
it in the future either, so I'll just orphan it again so that someone
who is really
On Fri, Apr 25, 2014 at 06:51:26PM -0400, Chuck Anderson wrote:
> I'm starting a new thread to clarify and emphasize the problem I'm
> actually trying to solve. Here is the problem restated as I posted it
> to the dns-operations list:
>
> -
> Is it really expected that the first DNS server li
Hi,
I don't have enough bandwidth to do anything useful with them any more,
so I'm orphaning them. LibRaw is a dependency for shotwell and gource
is, well, pretty neat.
Siddhesh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Resending since the last attempt bounced.
On Wed, Oct 16, 2013 at 03:21:31PM +0530, Siddhesh Poyarekar wrote:
> On Tue, Oct 15, 2013 at 10:27:36PM +0200, Reindl Harald wrote:
> > >> Do you really run "gnome-open --help" 1000 times per reasonable unit of
> > >&g
On Fri, May 17, 2013 at 11:25:31AM +0100, Daniel P. Berrange wrote:
> > Well, I don't think glibc info doc has only developer-targetted info -
> > that's the issue - there are more things useful to regular experienced
> > users (like regexps info, locales info).
>
> In that case, glibc maintainers
On Tue, Jul 12, 2016 at 09:49:14AM -0700, Adam Williamson wrote:
> To be clear, the idea would be to have general-purpose instructions for
> basic functionality testing of each package, not requiring new 'how to
> test' text to be written for every individual package update,
> specifically tailored
On Tue, Jul 12, 2016 at 11:38:01AM -0700, Adam Williamson wrote:
> This isn't really correct, because there is no simple relationship
> between 'bugs claimed to be fixed actually are fixed' and 'update
> should be released'. Both of these are possible:
>
> 1) an update which fixes the bugs it clai
On Tue, Jul 12, 2016 at 12:16:59PM -0700, Adam Williamson wrote:
> This is setting far too high a bar for a project like Fedora. We take
> the feedback we can get, we are not in a position to demand all update
> testers perform comprehensive testing of all possible facets of an
> update. It is alwa
On Tue, Jul 12, 2016 at 03:45:54PM -0700, Adam Williamson wrote:
> Bodhi works at the source package level, not binary package level.
I think Jon's point was with respect to the scope of testing. With
glibc (or libstdc++ that Jon would be concerned with), an ideal set of
sanity tests would cover
On Tue, Jul 12, 2016 at 09:23:26PM +0200, Reindl Harald wrote:
> nonsense - it's enough to give a sign that a potential fix don't break
> things wich worked before
Your point is valid without saying 'nonsense', so please be a bit more
civil.
I can live with a karma +1 for sanity tests if testing
On Tue, Jul 12, 2016 at 09:12:25PM -0700, Gerald B. Cox wrote:
> Instead of concentrating on testers, what about the packagers who don't
> even test their
> applications before throwing them over the wall to bodhi. I've seen
> packages that didn't even
> get past a simple dnf requisite test becaus
On Tue, Jul 12, 2016 at 10:26:20PM -0700, Adam Williamson wrote:
> It would not be 'a lot of work', it would be a gigantic, totally
> unsustainable burden. I honestly think you're shooting *way* too high
> here. Even with all the recent volunteers, we have like a couple dozen
I agree it is a massi
On Tue, Jul 12, 2016 at 11:52:45PM -0700, Adam Williamson wrote:
> FWIW, as someone who is working on this, I don't think we can
> realistically aim to do distribution-level automated testing with per-
> package granularity. We actually have all the bits in place to do
> something like that if we w
On Wed, Jul 13, 2016 at 01:23:04PM -0400, Przemek Klosowski wrote:
> I think the functionality you're talking about (checking correctness of bug
> fixes, etc) should be left to the original bug reporters. After all, they
> raised the issue so they are invested in the result.
Agreed.
> Automation
On Mon, Feb 25, 2013 at 11:49:49AM +0700, Michel Alexandre Salim wrote:
> - - Refactorig LLVM's build system to properly use versioned shared
> objects. I note that other distributions, and BSD, are still using
> static linking, so we appear to be the only ones attempting to package
> LLVM properly
On Friday 11 November 2016 12:46 AM, Florian Weimer wrote:
> We currently call /usr/lib/rpm/brp-strip-static-archive from
> %__os_install_post. This removes debugging symbols from static (.a)
> libraries.
>
> Is this really a good idea? Due to this, glibc copies libc.a to
> glibc-debuginfo, so t
On Monday 14 November 2016 02:18 PM, Florian Weimer wrote:
> Do you suggest that gcc should invoke ld with -S, unless gcc was invoked
> with some -g flags or -s?
Ideal behaviour would be to make ld smarter about debuginfo but I don't
know if that is doable, so this should do.
>> Otherwise we need
On Tuesday 15 November 2016 08:03 PM, Adam Jackson wrote:
> One does not build _programs_ with/out -g. One builds objects, and
> links objects into programs.
Sorry I did not word that correctly - I do know that emitting debuginfo
is a compile time operation but I wanted to make the case that when
On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
wrote:
>
> On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
> >
>
> It is my vague recollection (I could easily be wrong, so
> correct me as appropriate
On Mon, Dec 5, 2022 at 5:53 PM Neal Gompa wrote:
>
> On Mon, Dec 5, 2022 at 3:17 PM Gary Buhrmaster
> wrote:
> >
> > On Mon, Dec 5, 2022 at 7:58 PM Ben Cotton wrote:
> > >
> > > https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
> > >
> >
> > It is my vague
On Mon, Dec 5, 2022 at 7:35 PM Jaroslav Prokop wrote:
> Default C and C++ compiler flags to build packages in Fedora currently
> includes `-Wp,-D_FORTIFY_SOURCE=2`, which enables fortification of
> some functions in glibc, thus providing some mitigation against buffer
> overflows. Since glibc 2.3
On Mon, Dec 5, 2022 at 10:20 PM Gary Buhrmaster
wrote:
>
> On Mon, Dec 5, 2022 at 10:53 PM Neal Gompa wrote:
>
> > It has a similar impact that turning back on frame pointers would.
> >
> > Cf.
> > https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level#the_gains_of_improv
On Tue, Dec 6, 2022 at 4:05 AM Richard W.M. Jones wrote:
>
> On Tue, Dec 06, 2022 at 01:35:04AM +0100, Jaroslav Prokop wrote:
> > On 12/5/22 20:58, Ben Cotton wrote:
> >
> > The core change to bring in this mitigation is to change the default
> > build flags in `redhat-rpm-config` so that
On Tue, Dec 6, 2022 at 5:45 AM Jakub Jelinek wrote:
>
> On Tue, Dec 06, 2022 at 11:13:38AM +0100, Vitaly Zaitsev via devel wrote:
> > On 05/12/2022 20:58, Ben Cotton wrote:
> > > Replace the current `_FORTIFY_SOURCE=2` with `_FORTIFY_SOURCE=3` to
> > > improve mitigation of security issues arising
On Tue, Dec 6, 2022 at 8:14 AM Siddhesh Poyarekar wrote:
> > Please provide a proper "how to test" section, I cannot fix what I cannot
> > test or compare results when I have no idea what I am seeing.
> >
> > Actually, last time I heard about number of pac
On Tue, Dec 6, 2022 at 9:55 AM Siddhesh Poyarekar wrote:
>
> On Tue, Dec 6, 2022 at 8:14 AM Siddhesh Poyarekar wrote:
> > > Please provide a proper "how to test" section, I cannot fix what I cannot
> > > test or compare results when I have no idea what I am
On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster
wrote:
>
> On Tue, Dec 6, 2022 at 12:47 PM Siddhesh Poyarekar
> wrote:
>
> > Overall even if there is a miniscule performance overhead, I
> > reckon the reward is much higher.
>
> I am curious how you can cla
On Tue, Dec 6, 2022 at 10:26 AM Gary Buhrmaster
wrote:
>
> On Tue, Dec 6, 2022 at 3:16 PM Siddhesh Poyarekar wrote:
>
> > My full comment in that blog post is:
> >
> > "We need a proper study of performance and code size to understand the
> > magnitude of t
On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko
wrote:
> > On Tue, Dec 6, 2022 at 10:06 AM Gary Buhrmaster
> > >
> > My full comment in that blog post is:
> >
> > "We need a proper study of performance and code size to understand the
> > magnitude of the impact created by _FORTIFY_SOURCE=3 additi
On Wed, Dec 7, 2022 at 3:15 PM Andrii Nakryiko
wrote:
>
> > On Tue, Dec 6, 2022 at 12:56 PM Andrii Nakryiko
> > >
> > I don't think the two are comparable at all, neither in terms of
> > potential performance impact (register pressure across an entire
> > program vs at specific API call points in
[Responding from alias that's actually registered to devel@]
On Thu, Dec 8, 2022 at 8:25 AM Siddhesh Poyarekar wrote:
>
> On Mon, Dec 5, 2022 at 3:04 PM Ben Cotton wrote:
> >
> > On Mon, Dec 5, 2022 at 2:58 PM Ben Cotton wrote:
> > >
> > > * R
On Tue, Dec 6, 2022 at 10:41 AM Siddhesh Poyarekar wrote:
>
> On Tue, Dec 6, 2022 at 10:26 AM Gary Buhrmaster
> wrote:
> >
> > On Tue, Dec 6, 2022 at 3:16 PM Siddhesh Poyarekar
> > wrote:
> >
> > > My full comment in that blog post is:
> > &g
On Mon, Jan 9, 2023 at 5:53 PM Kevin Kofler via devel
wrote:
> * It made wrong assumptions about the performance impact of
> _FORTIFY_SOURCE=3, which, compared to the already existing (!)
> _FORTIFY_SOURCE=2, appears to actually have NO performance impact at all
> (!), only compared to no _FORTIFY
On Tue, Jan 10, 2023 at 3:05 AM Zbigniew Jędrzejewski-Szmek
wrote:
> Exactly, you're just confirming what I wrote above.
>
> A "vote being rigged" means that either the people who should be allowed to
> vote
> couldn't, or that people who are not allowed to vote did, or that voters were
> tricked
On Tue, Jan 10, 2023 at 4:31 PM Zbigniew Jędrzejewski-Szmek
wrote:
> That description assumes that FESCo members are preschoolers who are
> easy to trick and also need to be reminded who said what every day.
> That's certainly not the case. The objections against the proposal
> were made very clea
On Tue, Jan 10, 2023 at 7:17 PM Fabio Valentini wrote:
> Speaking for myself, the only way in which the _FORTIFY_SOURCE change
> impacted my opinion on -fno-omit-frame-pointers is that it made me
> think about it again, and that the level of scrutiny myself - and
> other members of FESCo - had giv
On Wed, Jan 11, 2023 at 6:25 AM Vít Ondruch wrote:
>
>
> Dne 11. 01. 23 v 12:16 Vít Ondruch napsal(a):
> > So shouldn't there be some policy for revoting? E.g.:
> >
> >
> > ~~~
> >
> > If revote is initiated (by somebody?), the revote is going to be
> > announced on devel(-announce) and can happen
On Wed, Jan 11, 2023 at 12:45 PM Michel Alexandre Salim
wrote:
> Is this supported yet? I'm doing a build of rubberband for Rawhide, and
> every file generates this warning:
>
> ../src/test/TestStretcher.cpp: warning: -D_FORTIFY_SOURCE defined but
> value is too low
Yes the change is in, it even
On Wed, Jan 11, 2023 at 1:15 PM Michel Alexandre Salim
wrote:
> The warning seems to happen only in mock, the Koji build is clean:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=96015653
>
> Let me paste the root.log and build.log from the local build (I'm now
> working on upgrading a secon
On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim
wrote:
> Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm`
>
> I have these additional knobs in ~/.config/mock.cfg:
>
>
> config_opts['plugin_conf']['ccache_enable'] = True
> config_opts['plugin_conf']['ccache_opts']['max_cache_size'] = '10G'
>
On Wed, Jan 11, 2023 at 4:37 PM Siddhesh Poyarekar wrote:
>
> On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim
> wrote:
> > Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm`
> >
> > I have these additional knobs in ~/.config/mock.cfg:
> >
> >
> &
On Wed, Jan 11, 2023 at 4:43 PM Siddhesh Poyarekar wrote:
> On Wed, Jan 11, 2023 at 4:37 PM Siddhesh Poyarekar
> wrote:
> >
> > On Wed, Jan 11, 2023 at 3:05 PM Michel Alexandre Salim
> > wrote:
> > > Just `mock -r fedora-rawhide-x86_64 ./*.src.rpm`
> > &
On Thu, Jan 12, 2023 at 12:41 PM Jakub Jelinek wrote:
> > I've filed a ccache bug. It looks like ccache is moving the compiler
> > arguments around, causing one of the -U_FORTIFY_SOURCE to the end.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2160275
>
> Why we do have those -U_FORTIFY_SOU
On Thu, Jan 12, 2023 at 6:38 PM Jakub Jelinek wrote:
> But at least you don't need both -U_FORTIFY_SOURCE and
> -Wp,-U_FORTIFY_SOURCE, one of them is enough. And the latter I think
> better gets through libtool and other tools; especially if you put it
> into a single -Wp, option together with th
On Mon, Jan 16, 2023 at 1:05 PM Daniel P. Berrangé wrote:
>
> I'm getting the strange error in $SUBJECT in an upstream CI job that
> is targetting Fedora rawhide. I'm guessing it is something related to
> the recent changes to set the _FOTIFY_SOURCE value to 3 instead of
> 2, but not sure what.
>
On Mon, Jan 16, 2023 at 1:40 PM Miro Hrončok wrote:
>
> Hello folks,
> this recent Fedora change:
>
> https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distribution_build_flags
>
> Made me think:
>
> Which compiler flags we need to store in Python and which can we omit?
>
> In order
On Fri, Jan 20, 2023 at 8:54 AM Richard Shaw wrote:
>
> So is it when a build is complete in Rawhide? Or must *ALL* active releases
> get the "fix"?
>
It depends on the severity of the CVE. For High severity ones it
makes sense to fix in all active releases, less so for Medium/Low
CVEs.
hth
S
On Sat, Aug 27, 2022 at 9:14 AM Carlos O'Donell wrote:
> (2) Switching the default vs. improving the default.
>
A third option (or maybe it's an improvement to the default?), since
the choice of allocators seems to come up consistently, could be to
consider seriously (and is likely not a trivial
On 2024-05-10 06:41, Miro Hrončok wrote:
Hello,
when we build Python 3.13 with -O3
https://fedoraproject.org/wiki/Changes/Python_built_with_gcc_O3
I see the following annocheck problem:
Hardened: /usr/bin/python3.13: MAYB: test: fortify, reason:
-D_FORTIFY_SOURCE=2 detected, expected -D_FORT
> See https://koschei.fedoraproject.org/package/ocaml-dune?collection=f34
> Can the change be reverted until we can figure out exactly which
> packages will have to be rebuilt?
I've got a build going with that and a couple of other patches reverted.
-12.f34 should unbreak this.
This really shou
> It's going to come back because its removal breaks compatibility with
> the 2001 POSIX standard. But I expect there will be plenty of
> deprecation warnings around it.
It should be back now in -12.fc34, which is currently building.
Siddhesh
___
devel
On Mon, May 16, 2022 at 7:18 PM Mark Wielaard wrote:
>
> Hi Steve,
>
> On Wed, 2022-05-11 at 22:35 -0400, Steve Grubb wrote:
> > On Monday, May 9, 2022 5:10:07 AM EDT Daniel P. Berrangé wrote:
> > > Are you going to take this idea forward and make a formal change proposal
> > > for Fedora to set -
[Fixing up my mailing list settings and re-sending]
Hello,
Apologies for the delayed announcement but as of
glibc-2.34.9000-13.fc35, the glibc package has been split to create a
new package glibc-gconv-extra to hold most converter modules into a
separate package. The common converters such as th
On Tue, Jun 22, 2021 at 3:56 PM Miro Hrončok wrote:
>
> On 22. 06. 21 4:48, Siddhesh Poyarekar wrote:
> > This may result in testing failures when
> > applications try to test uncommon character set conversions. The fix
> > to get that working again is to add a build
On Fri, Jun 25, 2021 at 10:47 AM Zdenek Dohnal wrote:
> Aha, it seems the rawhide buildroot from 6/23 still contained glibc with
> recommends on new package and not hard requires.
Sorry yes, we haven't done a build yet. I expect one to come out next
week with this fix and the fix for some other
[cursed email aliases!]
On Tue, Aug 24, 2021 at 10:42 AM Siddhesh Poyarekar wrote:
>
> On Tue, Aug 24, 2021 at 2:52 AM Richard W.M. Jones wrote:
> > Anyway this is not the reason why I'm writing this email on Fedora
> > devel list. In the Fedora package we have:
> &g
On Tue, Aug 24, 2021 at 1:28 PM Richard W.M. Jones wrote:
> Thanks - I made this change to nbdkit:
>
> https://gitlab.com/nbdkit/nbdkit/-/commit/8972831aa2a32d4b5820465d37c1827eb76450e4
>
> Will the .0 ever change?
I can't see a reason for it to ever change; I'd say it's unlikelier
than the .6 in
On 2025-02-10 18:39, Neal Gompa wrote:
On Mon, Feb 10, 2025 at 6:21 PM Fabio Valentini wrote:
On Mon, Feb 10, 2025 at 11:48 PM Tom Rix wrote:
I am glad the gcc change came in before the branch.
But I would rather it have come into rawhide after the branch so the last weeks
before the branc
On 2025-01-30 17:33, Kevin Fenzi wrote:
On Wed, Jan 29, 2025 at 10:01:09AM +0100, Vít Ondruch wrote:
Thanks for clarifying. Of course one reason for mass rebuild can be that we
are not able to properly identify the package set for more targeted mini
mass rebuild.
But IMHO, having just the Copr
On 2025-01-27 14:55, Michal Schorm wrote:
Alright, thanks for the explanation.
In that case, I think the RFC is a step in the right direction,
but I don't see it being useful, unless the change owners do the extra
step and file the FTBFS bugs to notify the maintainers.
They can do it already, bu
On 2025-01-28 13:53, Vít Ondruch wrote:
Dne 28. 01. 25 v 18:53 Siddhesh Poyarekar napsal(a):
On 2025-01-28 05:19, Vít Ondruch wrote:
4) Having everything rebuild by GCC 15? That on itself is not a goal
IMHO. Making sure everything works with GCC 15 is good goal, but that
is problem for
On 2025-01-28 05:19, Vít Ondruch wrote:
4) Having everything rebuild by GCC 15? That on itself is not a goal
IMHO. Making sure everything works with GCC 15 is good goal, but that is
problem for developers, not for users (we can argue if there are CVEs,
this might become problem, but this is not
On 2025-01-28 06:00, Vít Ondruch wrote:
This is debatable. Realistically, failure due to GCC does not need to be
fixed everywhere until really needed. It is good to have it fixed in
Rawhide to be ready for backport when needed.
Build failures don't *have* to be fixed right away, but in practic
On 2025-01-28 04:08, Karolina Surma wrote:
Regarding the gcc prebuild: I'd personally prefer to deal with a report
that may end up redirected to the gcc team or closed as not a bug weeks
in advance than being surprised by the build failure when an update
lands in Rawhide.
Thank you, that's us
On 2025-01-15 13:51, Miro Hrončok wrote:
On 15. 01. 25 17:15, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jan 15, 2025 at 05:06:47PM +0100, Karolina Surma wrote:
Hi,
My Python 3.14 builds have started pulling gcc 15 in Fedora Rawhide (no
side-tag). Is this intentional?
It seems so. https://bo
On 2025-01-15 20:46, Fabio Valentini wrote:
TBH we haven't had enough time since upstream gcc stage 1 close to
finish going through all the failures[1]. If only we had a week or two
more for the mass rebuild; it got delayed by a couple of weeks last
year
and a similar delay w
On 2025-01-16 07:22, Siddhesh Poyarekar wrote:
On 2025-01-15 20:46, Fabio Valentini wrote:
TBH we haven't had enough time since upstream gcc stage 1 close to
finish going through all the failures[1]. If only we had a week
or two
more for the mass rebuild; it got delayed
91 matches
Mail list logo
