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
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-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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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
[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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 -
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
[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 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
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
[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
> 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
> 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
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 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 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 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 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 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 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 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 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 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 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 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 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
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
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 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
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 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 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 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 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 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 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 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
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 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
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
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
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 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/
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 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
>
>
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 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
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
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 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'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, 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
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 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
84 matches
Mail list logo
