Hi Florian,
On Thu, Jun 26, 2025 at 11:02:51AM +0200, Florian Weimer wrote:
> * Chris Adams:
> > Once upon a time, David Airlie said:
> >> Does anyone know if it's possible to install i686 build deps into an
> >> x86-64 build?
> >>
> >> I was going to try and see what building a mesa package tha
Hi,
On Wed, Jun 25, 2025 at 08:45:33PM +0100, Jonathan Wakely wrote:
> On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote:
> >
> > And there is another aspect, Fedora being used often as a distribution used
> > by developers working on compilers and other parts of toolchain. Not having
> > at leas
Hi Nick,
On Fri, Jan 17, 2025 at 10:31:49AM +, Nick Clifton wrote:
> >But I also think this is a bug in binutils readelf (CCing nickc).
> >
> >It really should not even try to print the "interpreter" of a separate
> >debuginfo file.
>
> Well yes and no. One of the main uses of readelf is to
Hi! (Added nickc to the CC, see below)
On Wed, Jan 15, 2025 at 01:52:24PM +0100, Miro Hrončok wrote:
> On 15. 01. 25 10:18, Robin Jarry wrote:
> >I found out that rpmlint errors out without producing any meaningful result
> >when the analyzed RPMs contain binaries:
> >
> > sh-5.2# strace -f -e tr
Hi Richard,
On Thu, Nov 28, 2024 at 06:52:28PM +, Richard W.M. Jones wrote:
> On Thu, Nov 28, 2024 at 06:30:14PM +0100, Mark Wielaard wrote:
> > As others already analyzed this is because debugedit added error
> > checking for gdb-add-index in debugedit 5.1. Which is good. Exce
Hi,
Sorry, I missed this thread. Please do feel free to file a bugzilla
against debugedit for these kind of issues.
On Mon, 2024-11-25 at 14:36 +0100, Jaroslav Škarvada wrote:
> the tcl package build started to fail with the same error in rawhide [1]:
> /usr/bin/find-debuginfo -j4 --strict-build
Hi Panu,
On Wed, Jun 05, 2024 at 09:26:14AM +0300, Panu Matilainen wrote:
> On 6/4/24 21:43, Frank Ch. Eigler wrote:
> >dvlasenk wrote:
> >
> >>[...] Do you understand how many fetches of debuginfo will be
> >>attempted by e.g. a kernel build tooling when it runs readelf on 8000
> >>freshly built
Hi,
On Wed, Jul 12, 2023 at 03:38:35PM -0600, Jerry James wrote:
> On Wed, Jul 12, 2023 at 3:34 PM Richard W.M. Jones wrote:
> > I looked through the section names with objdump -h and none of them
> > looked unusual. However I think in the past when we analyzed this we
> > found it was doing som
Hi,
On Wed, Jul 12, 2023 at 09:54:49AM -0600, Jerry James wrote:
> On Wed, Jul 12, 2023 at 4:38 AM Richard W.M. Jones wrote:
> > During the OCaml 5 rebuild I found there's a generic problem on s390x
> > & ppc64le (ie. the bytecode-only architectures) involving stripping of
> > OCaml binaries. [..
Hi Andy,
(Please do put me on CC, I do try to read all of devel list, but it is easy to
miss something)
On Tue, May 02, 2023 at 11:42:30AM -, Andy Li wrote:
> Sorry for the late reply. I just got back to this issue.
>
> > In general this (should) only happen if the binaries are really
> > i
Hi,
On Thu, Apr 20, 2023 at 07:21:54PM -0400, Simo Sorce wrote:
> The mailing list make messages land in my client, on which I am very
> efficient, therefore I can check all messages once a day, and respond
> if I find a worthy topic.
>
> Unless this discourse has some great mail bridge (it doesn
Hi Florian,
On Wed, 2023-01-18 at 15:01 +0100, Florian Weimer wrote:
> We won't have unwind data for JIT-compiled code, including libffi
> trampolines. We could stop backtracing there (what does the ABI say
> about frames without unwinding information?), but I'm not sure if
> that's
> going to be
Hi Florian,
On Wed, 2023-01-18 at 07:22 +0100, Florian Weimer wrote:
> * Daniel Colascione:
>
> > See, both pro-FP and anti-FP camps think that it's the kernel that has
> > to do the unwinding unless we copy whole stacks into traces.
>
> Well, I think we should explore hardware-assisted backtrac
Hi Daniel,
On Mon, Jan 16, 2023 at 08:30:21PM -, Daniel Colascione wrote:
> As mentioned in [1], instead of finding a way to have the kernel
> unwind user programs, we can create a protocol through which the
> kernel can ask usermode to unwind itself.
I like this idea and was discussing and t
Hi Matthew,
On Mon, Jan 09, 2023 at 11:47:54AM -0500, Matthew Miller wrote:
> On Sun, Jan 08, 2023 at 06:06:47PM +0100, Kevin Kofler via devel wrote:
> > Therefore, I hereby request that the vote be annulled as having happened
> > in violation of the Change policy.
>
> So, from a purely "what are
Hi Neal,
On Wed, 2023-01-04 at 08:44 -0500, Neal Gompa wrote:
> On Wed, Jan 4, 2023 at 8:30 AM Vitaly Zaitsev via devel
> wrote:
> >
> > Already rejected proposal was submitted because big corporations
> > weren't
> > happy with the results. This is a VERY BAD precedent for Fedora.
> >
>
> Act
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 -ftrivial-auto-var-init=zero by default in its default
> > RPM build
Hi,
On Thu, Jan 27, 2022 at 10:41:36AM +0100, Roberto Ragusa wrote:
> On 1/22/22 10:05 PM, Mark Wielaard wrote:
>
> > So I would give valgrind a 6/6 (100%) score :)
>
> But if the compiler starts copying zeros on uninitialized memory,
> valgrind loses any ability to det
Hi Steve,
On Fri, 2022-01-21 at 13:04 -0500, Steve Grubb wrote:
> This is a continuation of the discussion from F36 Change: GNU
> Toolchain Update.
>
> Uninitialized variables are a big problem. They can be sources of information
> exposure if parts of a buffer are not initialized. They can also
On Sat, 2022-01-22 at 20:49 +, Richard W.M. Jones wrote:
> On Sat, Jan 22, 2022 at 03:00:14PM -0500, Steve Grubb wrote:
> > On Saturday, January 22, 2022 6:36:01 AM EST Vitaly Zaitsev via
> > devel wrote:
> > > On 21/01/2022 19:04, Steve Grubb wrote:
> > > > Uninitialized variables are a big pr
Hi,
On Thu, 2022-01-20 at 17:56 -0500, Marek Polacek wrote:
> On Tue, Jan 11, 2022 at 05:00:57PM -0500, Carlos O'Donell wrote:
> > On 1/11/22 13:00, Steve Grubb wrote:
> > > Reading through the GCC 12 changes, there is a significant new feature to
> > > GCC
> > > that would appear to be useful f
Hi Lennart,
On Thu, 2021-10-28 at 09:56 +0200, Lennart Poettering wrote:
> But as someone who's at the upstream receiving end of bug
> reports
> of one major project I can tell you that MiniDebugInfo is literally
> the best thing since sliced bread: in systemd upstream the bug reports
> we get fro
Hi Daniel,
On Wed, 2021-10-27 at 10:01 +0100, Daniel P. Berrangé wrote:
> Getting RPM NEVRs directly from the coredumps is something that
> will be incredibly helpful for people dealing with support
> requests after crashes. build-ids have always been very tedious
> to deal with and as you say RPM
Hi,
On Mon, 2021-10-25 at 15:09 -0400, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects
I like this idea. It will be really useful when multiple distros adopt
it.
> === New system: `.note.package` ===
>
> The new note is created and propagated simila
Hi,
On Thu, 2021-10-14 at 16:49 +0200, Kamil Dudka wrote:
> As I understand it, Zbyszek is now proposing to make changes to other
> packages
> and/or distribution metadata in order to make (lib)curl-minimal actually used
> on some Fedora installations by default.
This sounds interesting. For e
On Tue, 2021-07-13 at 14:52 +0200, Petr Pisar wrote:
> V Tue, Jul 13, 2021 at 02:27:57PM +0200, Mark Wielaard napsal(a):
> > Or How do you trigger a fedora-ci.koji-build.tier0.functional run for a
> > package?
> >
>
> $ bodhi updates trigger-tests UPDATE_ID
Thanks!
Hi,
For valgrind we added some integration tests, and they seem useful (for
example they caught a change in gdb breakpoint location when set after
attaching to the valgrind gdbserver). But sometimes they don't trigger
and then the package is just stuck waiting till the CI tests are ran.
For examp
Hi Rich,
On Tue, Jun 08, 2021 at 04:09:33PM +0100, Richard W.M. Jones wrote:
> I haven't filed a bug yet because I'm not sure what component to
> assign this too. I upgraded to Rawhide this morning and noticed that
> some tests that previously ran OK are now timing out. It turned out
> that the
Hi Guillem,
On Wed, 2021-05-19 at 02:19 +0200, Guillem Jover wrote:
> So this is where I guess I'm missing something. To be able to make
> sense of the coredumps there are two things that might end up being
> relevant, backtraces and source code. systemd-coredump might already
> emit a backtrace,
Hi Luca,
On Tue, 2021-05-04 at 14:43 +0100, Luca Boccassi wrote:
> On Fri, 2021-04-30 at 19:57 +0200, Mark Wielaard wrote:
> > Is there a list of default keys (and their canonical spelling, upper-
> > lower-Camel_Case, etc.)? If there is, could we have a "debuginfod" key
Hi,
On Sat, 2021-04-10 at 18:44 +, Zbigniew Jędrzejewski-Szmek wrote:
> [I'm forwarding the mail from Luca who is not subscribed to fedora-
> devel]
> On Sat, Apr 10, 2021 at 01:38:31PM +0100, Luca Boccassi wrote:
> Cross-posting to the mailing lists of a few relevant projects.
Note that in t
Hi Florian,
On Thu, 2021-04-29 at 16:33 +0200, Florian Weimer wrote:
> I need to wrap find-debuginfo.sh because there is a single shared
> object
> in my package that must not be stripped. find-debuginfo.sh does not
> support that, and probably never will, at least not in its current
> shell-base
Hi,
On Fri, 2021-04-23 at 20:01 +0200, Jakub Jelinek wrote:
> On Fri, Apr 23, 2021 at 11:18:59AM -0400, Ben Cotton wrote:
> > The Red Hat tools team believes that LLVM/Clang and GCC should be
> > considered equals from
> > a Fedora policy standpoint. Selection of one toolchain over the other
> >
On Wed, Apr 14, 2021 at 04:04:21PM +0200, Robert-André Mauchin wrote:
> On 4/14/21 3:28 PM, Mark Wielaard wrote:
> > I got a "pull request" for one of my packages and wanted to make some
> > changes to discuss with the submitter and see if we could merge it
> >
On Wed, Apr 14, 2021 at 02:38:40PM +0100, Tom Hughes via devel wrote:
> On 14/04/2021 14:28, Mark Wielaard wrote:
>
> > I added the following line to my .git/config at the end of the [remote
> > "origin"] section to be able to pull it:
> >
> > fetch =
Hi,
I got a "pull request" for one of my packages and wanted to make some
changes to discuss with the submitter and see if we could merge it
back with those changes to the rawhide branch. But somehow I did
something wrong and I am not sure what or how to fix it.
So I saw this webpage with the sug
Hi Mamoru,
On Fri, 2021-01-22 at 22:27 +0900, Mamoru TASAKA wrote:
> It looks like new dwz-0.13-6.fc34 is silently segfaulting when
> rebuilding some srpm,
> but it does not prevent whole rpmbuild process from stopping.
>
> Some random example:
> * vorbis-tools-1.4.2-1.fc34
>https://koji.fedo
Hi Tom,
On Mon, 2020-11-30 at 14:06 -0800, Tom Stellard wrote:
> As part of the f34 change request[1] for removing make from the
> buildroot, I will be doing a mass update of packages[2] to add
> BuildRequires: make where it is needed.
As part of a previous change request [1] various packages w
Hi Andy,
On Fri, 2020-11-13 at 02:16 +, Andy Li wrote:
> Re. https://bugzilla.redhat.com/show_bug.cgi?id=1896901
>
> Since haxe-4.1.3-4 and nekovm-2.3.0-4, both nekovm and haxe packages
> contains "/usr/lib/.build-
> id/b0/aed4ddf2d45372bcc79d5e95d2834f5045c09c".
> The nekovm one is a symlink
On Tue, Oct 06, 2020 at 04:46:24PM -0600, Jeff Law wrote:
>
> On 9/30/20 3:50 AM, Jan Kratochvil wrote:
> > On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
> >> But the GCC community
> >> doesn't really test that option and it's known to be broken with LTO.
> > I haven't seen any GCC PR for -f
Hi,
Changing subject because this has nothing to do with that Change
Proposal anymore.
On Tue, Oct 06, 2020 at 01:49:13PM -0600, Jeff Law wrote:
> However, I think it's perfectly valid to discuss zstd if folks wanted to
> change the compression scheme for debug sections. In fact, I'd claim
> sti
Hi Neal,
On Tue, 2020-09-29 at 19:59 -0400, Neal Gompa wrote:
> For the record, Mark has started implementing DWARF-5 support in dwz:
> https://sourceware.org/git/?p=dwz.git;a=log
>
> I think I would rather like to see a Change proposal to switch to
> DWARF-5 for Fedora 34, especially since it lo
Hi Jan,
On Mon, Sep 28, 2020 at 04:50:59PM +0200, Jan Kratochvil wrote:
> To make DWZ better consumable it needs to have the partial units separately
> parseable. That way they can be shared at IR level and not just at DWARF
> level
> That means:
> * DW_TAG_partial_unit should have DW_AT_language
On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 17:35:26 +0200, Jakub Jelinek wrote:
> > So, was this compiled by GCC or clang?
>
> Fedora Koji package:
> lldb-debuginfo-11.0.0-0.2.rc3.fc34.x86_64
>
> GNU GIMPLE 10.2.1 20200916 (Red Hat 10.2.1-4) -m64 -
Hi Jan,
On Mon, Sep 28, 2020 at 05:28:57PM +0200, Jan Kratochvil wrote:
> On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote:
> > I do find your statistics per package useful because they show dwz is
> > in general effective by producing at least 20% (more) on-disk size
> &
Hi,
On Fri, 2020-09-25 at 17:18 +0200, Florian Weimer wrote:
> * Robbie Harwood:
> > Jan Kratochvil writes:
> > > So why is Google using it for everything?
> >
> > If I could eliminate one bad thought pattern in software design it would
> > probably be this one.
> >
> > In brief: you are not Go
Hi Jan,
On Fri, 2020-09-25 at 11:43 +0200, Jan Kratochvil wrote:
> On Fri, 25 Sep 2020 01:35:43 +0200, Mark Wielaard wrote:
> > Replying since I am mentioned by name in this proposal and it seems to
> > argue for removing a feature I am currently working on to make sure it
>
On Thu, Sep 24, 2020 at 08:34:48PM +0200, Jan Kratochvil wrote:
> > The tool is not easily maintained,
>
> I did not mention it there but it is true there are some longterm unfixed
> bugs in DWZ so that it gives up on optimization of many builds:
> error: Allocatable section after non-alloca
d you adding .debug_names support if you believe it to be
better than .gdb_index.
> * DWZ disadvantage: DWZ DWARF-5 support is a work-in-progress. DWZ has
> been blocking DWARF-5 for Fedora for 3.5 years and only after I have
> now proposed to drop DWZ Mark Wielaard has started porting D
Hi,
I couldn't build elfutils because of an annobin bug that showed up on
ppc64le. Nick was nice enough to fix it and push a new annobin version:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-c78fce452e
So I could build elfutils again:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-06da
Hi,
On Mon, 2020-09-21 at 08:55 +0300, Panu Matilainen wrote:
> On 9/21/20 12:25 AM, Marcin Zajączkowski wrote:
> > Hi. There is an ongoing problem with conflicting build-ids in chromium
> > and chromium-freeworld [1][2]:
> > > Error: Transaction test error:
> > >file /usr/lib/.build-id/61/91a
Hi Richard,
On Tue, Aug 04, 2020 at 09:55:45AM +0100, Richard W.M. Jones wrote:
> In https://kojipkgs.fedoraproject.org//work/tasks/5877/48605877/build.log
> (from https://koji.fedoraproject.org/koji/taskinfo?taskID=48605877)
> I'm still seeing errors like:
>
> /usr/lib/rpm/debugedit:
> /build
On Fri, 2020-07-31 at 12:44 +0100, Richard W.M. Jones wrote:
> On Fri, Jul 31, 2020 at 10:40:57AM +0100, Nick Clifton wrote:
> > That binutils was rebuilt (thanks to Richard Jones) and I have now
> > built an even newer one which contains a fix for AArch64 PLT problems.
> > Both of these are built
Hi Aleksandra,
On Thu, 2020-07-30 at 12:24 +0200, Aleksandra Fedorova wrote:
> I'd like to get some understanding on the current state of emulation
> of other architectures.
>
> In the current CI infra we have infinite(*) access to x86_64 compute
> resources, but we haven't yet got our hands on a
On Thu, 2020-07-30 at 10:09 +0200, Kevin Kofler wrote:
> Jeff Law wrote:
> > :( I'll raise it again with Nick and Jakub, it's a sore point for
> > everyone I think and it causes far more friction than just what we see
> > here in Fedora.
>
> IMHO, we should just drop annobin from Fedora (or at le
Hi Richard,
On Thu, 2020-07-30 at 12:01 +0100, Richard W.M. Jones wrote:
> On Thu, Jul 30, 2020 at 08:37:05AM +0100, Nick Clifton wrote:
> > I will apply this patch to the rawhide binutils (and the upstream
> > binutils sources).
>
> I don't know how worried we should be about this, but it seems
Hi Jakub,
On Wed, 2020-07-29 at 19:10 +0200, Jakub Jelinek wrote:
> On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote:
> > Yes, I think we have a winner!
> > gas generates a tiny bit of debuginfo even if you don't supply -g.
> >
> > But... in 2.35
Hi Richard,
On Wed, 2020-07-29 at 17:55 +0100, Richard W.M. Jones wrote:
> On Wed, Jul 29, 2020 at 06:33:45PM +0200, Mark Wielaard wrote:
> > This, defaulting to version 4. Fixes it for me:
> >
> > diff --git a/gas/as.c b/gas/as.c
> > index 4c5881abd88..c2da78870e
Hi Xavier,
On Wed, 2020-07-29 at 18:50 +0200, Xavier Leroy wrote:
> If we need to add a directive to the generated assembly, or pass a `-g`
> option to the assembler, or use `gcc -c -g` as the assembler, let us know
> and we'll see what we can do.
>
> However, please keep backward compatibility i
Hi,
On Wed, 2020-07-29 at 17:18 +0100, Richard W.M. Jones wrote:
> (Adding OCaml author)
(Adding binutils/gas maintainer)
> On Wed, Jul 29, 2020 at 05:54:52PM +0200, Mark Wielaard wrote:
> > On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote:
> I should probably add th
Hi Richard,
On Wed, 2020-07-29 at 16:07 +0100, Richard W.M. Jones wrote:
> On Wed, Jul 29, 2020 at 04:11:56PM +0200, Mark Wielaard wrote:
> > Given these are .ml files I suspect it is not gcc, but some other
> > code/DWARF generator issue. Maybe it does use the default
> >
Hi,
On Wed, 2020-07-29 at 08:05 -0600, Jeff Law wrote:
> On Wed, 2020-07-29 at 13:15 +0100, Richard W.M. Jones wrote:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=48101965 fails
> > with:
> >
> > error: Empty %files file
> > /builddir/build/BUILD/hevea-2.34/debugsourcefiles.list
> >
Hi,
On Thu, 2020-07-23 at 09:59 +0200, Fabio Valentini wrote:
> On Thu, Jul 23, 2020 at 1:25 AM Mark Wielaard
> > I committed the removal of the two static subpackages and added an
> > Obsoletes: elfutils-devel-static%{depsuffix} < 0.180-5 to elfutils-
> > devel and an Ob
Hi,
On Tue, 2020-07-21 at 15:21 -0700, Josh Stone wrote:
> On 7/21/20 3:12 PM, Mark Wielaard wrote:
> > > > Is there a procedure to follow for dropping these sub-packages, or can
> > > > I simply remove them from the spec file?
> > >
> > > Maybe ad
Hi,
On Wed, 2020-07-22 at 09:32 -0400, Neal Gompa wrote:
> On Wed, Jul 22, 2020 at 9:19 AM Tom Hughes via devel
> wrote:
> >
> > On 22/07/2020 13:19, Mark Wielaard wrote:
> >
> > > As you say, the web api is even more resourceful and we can integrate
>
Hi Tom,
On Tue, 2020-07-21 at 13:53 +0100, Tom Hughes via devel wrote:
> On 21/07/2020 13:12, Mark Wielaard wrote:
> > > I normally just edit .git/config and add to the origin remote
> > > an extra fetch:
> > >
> > > fetch = +refs/pull/*/head:refs/remote
Hi Josh,
On Tue, 2020-07-21 at 14:47 -0700, Josh Stone wrote:
> On 7/21/20 2:24 PM, Mark Wielaard wrote:
> > Nothing seems to require these packages, but that might be simply be
> > because they are static libraries, so there aren't any runtime
> > requirements. Is ther
Hi,
I would like to drop the elfutils-libelf-devel-static and elfutils-
devel-static subpackages which provide static libraries for libelf and
libdw/libasm. They seem to have been provided a long time ago for some
core binaries, like rpm, to provide static binaries. But it looks like
nothing is us
On Tue, 2020-07-21 at 12:25 +0100, Tom Hughes via devel wrote:
> On 21/07/2020 11:56, Mark Wielaard wrote:
>
> > Do you have to handle them on that pagure website? Is it possible
> > to
> > handle these pull-request through email? Or is there a normal (git)
> > co
Hi,
I got a pagure pull-request for my package (a first!).
But I am slightly confused how to handle this.
The email that pagure sents is not very helpful since it doesn't
include the actual patch to try out. Also when I replied to the email
it seems to have not gone to the actual submitter (and j
Hi Jeff,
On Fri, 2020-06-05 at 10:07 -0600, Jeff Law wrote:
> On Fri, 2020-06-05 at 15:56 +, devel-requ...@lists.fedoraproject.org
> wrote:
> > One issue I am concerned about here is debuginfo quality. GCC produced
> > pretty bad debuginfo with LTO in older versions. The EarlyDebug work
> > d
Hi,
On Fri, 2020-06-05 at 09:25 -0600, Jeff Law wrote:
> The LTO bytecode streams do not survive past any given package build. ie,
> they
> are used within the build, then discarded. They're not supposed to show up in
> any installed libraries.
>
> Thus the fact that the two compilers use tota
On Fri, 2020-06-05 at 11:19 +0200, Jakub Jelinek wrote:
> On Fri, Jun 05, 2020 at 09:52:09AM +0200, Kevin Kofler wrote:
> > I do not see why we should allow yet another special case for Firefox, nor
> > why we should let random packages make their own choice of compiler and
> > risk
> > running
Hi,
On Mon, 2020-04-06 at 09:49 -0400, Ben Rosser wrote:
> > Not everyone is inclined to loudly argue their positions on the
> > mailing
> > list. There have only been 12 unique participants to this thread and 57
> > to the other thread.
> >
> > That isn't indicative of the entire Fedora packager
Hi,
I made a typo in the elfutils.spec for elfutils-0.178-3.fc32 which
broke the provide/requires dependency for elfutils-libelf. I fixed it
in elfutils-0.178-4. But I cannot get it to build in koji because
rpmbuild depends on elfutils and sees the broken requires.
Is there a way to remove elfuti
Hi fedora devel list,
The new elfutils upstream comes with a debuginfod server which we want
packaged (as a sub-package) for fedora. Testing looks good and
everything seems to work, but rpmlint flags a couple of issues that I
don't think should be real issues. Could someone help me understand why
Hi Jan,
CC systemtap upstream list, because I think this is not a great error
message.
On Fri, 2019-09-06 at 09:53 +0200, Jan Synacek wrote:
> I'm trying to run systemtap on F29 and I'm getting the following
> error:
>
> $ sudo stap -v journal.stap
> Pass 1: parsed user script and 491 library sc
Hi Jan,
CC systemtap upstream list, because I think this is not a great error
message.
On Fri, 2019-09-06 at 09:53 +0200, Jan Synacek wrote:
> I'm trying to run systemtap on F29 and I'm getting the following
> error:
>
> $ sudo stap -v journal.stap
> Pass 1: parsed user script and 491 library sc
Hi Kevin,
On Sun, 2019-07-14 at 15:50 -0700, Kevin Fenzi wrote:
> On 7/14/19 2:35 PM, John Reiser wrote:
> > Kevin Fenzi wrote:
> > > Neal Gompa wrote:
> >
> > [[snip]]
> >
> > > > This will also make it impossible for people to locally do multilib
> > > > build/installs. It will remove COPR’s a
Hi,
On Thu, 2019-03-28 at 14:28 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Mar 28, 2019 at 02:14:31PM +0100, Jakub Jelinek wrote:
> > On Thu, Mar 28, 2019 at 08:52:18AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Wed, Mar 27, 2019 at 01:55:44PM +, Zbigniew Jędrzejewski-Szmek
>
On Sat, Mar 23, 2019 at 07:07:53AM -0700, John Reiser wrote:
> The output dhat.out.3759 should be created in the current directory
> or at the destination specified by valgrind's usual --xml-*=
> command-line parameters. This is no different from any other output
> generated by valgrind.
Yes,
Hi,
The next release of valgrind (3.15.0) will have an updated dhat tool
which creates a json output file. To make it easier to use the data it
comes with a small html/css/js "application" that makes it easy to
sort/visualize the data.
This html/css/js application is self-contained, it doesn't us
On Tue, 2019-01-15 at 10:40 -0600, Richard Shaw wrote:
> Ooooaaa...
>
> So this has been around since at least 2017 and there's no fix?
Much longer than that. At least since 2012, probably earlier.
%exclude is discouraged, which is why it doesn't seem to have higher
priority. See also:
ht
On Wed, 2018-09-05 at 18:04 +0100, Richard W.M. Jones wrote:
> On Wed, Sep 05, 2018 at 06:40:47PM +0200, Mark Wielaard wrote:
> > We don't know the exact release version, but given the build-id
> > [0aea4b30d53d7cc6386f1773a8dc8972793def1a] we should be able to
> > match
On Wed, Sep 05, 2018 at 04:30:59PM +0100, Richard W.M. Jones wrote:
> On Wed, Sep 05, 2018 at 05:23:45PM +0200, Mark Wielaard wrote:
> > On Wed, 2018-09-05 at 13:59 +0100, Richard W.M. Jones wrote:
> > > On Wed, Sep 05, 2018 at 02:27:44PM +0200, Florian Weimer wrote:
> >
On Wed, 2018-09-05 at 13:59 +0100, Richard W.M. Jones wrote:
> On Wed, Sep 05, 2018 at 02:27:44PM +0200, Florian Weimer wrote:
> > But which one? For 2.28-9.fc29 or 2.27.9000-35.fc29? If GDB can't
> > find the build ID, I'd suggest try the other version as well.
>
> Oh I see, good point. I only
On Sun, 2018-08-05 at 15:55 -0700, Samuel Sieb wrote:
> On 08/05/2018 01:13 PM, Florian Weimer wrote:
> > There already is such a macro, %{valgrind_arches}, but it may not
> > accurately reflect the suitability of the run-time behavior of valgrind
> > on a particular architecture. For example, t
On Sun, 2018-08-05 at 22:13 +0200, Florian Weimer wrote:
> On 08/05/2018 09:48 PM, Samuel Sieb wrote:
> > What am I missing here? Why can't this be put in RPM macros? Then when
> > the situation changes in the future, there's only one place to change.
>
> There already is such a macro, %{valgri
On Sat, 2018-07-21 at 18:52 +0200, Mark Wielaard wrote:
> The elfutils tools can demangle C++ symbols through the standard
> _cxa_demangle interface. The elfutils tools are written in C and
> so simply link with -lstdc++ to get access to __cxa_demangle.
>
> There is a BuildRe
On Wed, 2018-07-25 at 21:04 +0300, Pavel Alexeev wrote:
> On 07/23/2018 12:36 PM, Dan Horák wrote:
> > On Mon, 23 Jul 2018 10:43:43 +0200
> > Mark Wielaard wrote:
> >
> > > On Sun, Jul 22, 2018 at 10:52:38PM +0300, Pavel Alexeev wrote:
> > > > Hello.
&
On Sun, Jul 22, 2018 at 10:52:38PM +0300, Pavel Alexeev wrote:
> Hello.
>
> I try build new version of perdition package.
>
> It build fine (https://koji.fedoraproject.org/koji/taskinfo?taskID=28526416)
> on all architectures except armv7hl and s390x. On that I got
> (https://kojipkgs.fedoraproje
Hi,
The elfutils tools can demangle C++ symbols through the standard
_cxa_demangle interface. The elfutils tools are written in C and
so simply link with -lstdc++ to get access to __cxa_demangle.
There is a BuildRequires: libstdc++-devel in the elfutils.spec.
But it looks like that isn't enough a
Hi,
On Tue, Mar 13, 2018 at 03:31:40PM +0100, Florian Weimer wrote:
> On 03/13/2018 03:03 PM, Jakub Jelinek wrote:
> > The right fix would be to make koji deal with multilibs properly,
> > mock can handle that fine already, then glibc32 wouldn't be needed at all.
>
> I think we requested these fe
On Fri, 2018-03-09 at 14:07 +0100, Florian Weimer wrote:
> Some x86_64 packages need a 32-bit glibc during build time. Koji
> does not provide it.
> [...]
> Comments? Suggestions?
Why don't we just make koji provide it?
That is how a normal 64bit Fedora install looks like. Those have the
32bit p
Hi Igor,
On Wed, 2018-02-14 at 21:59 +0100, Igor Gnatenko wrote:
> Your options:
>
> * Speak up and tell package names I should not touch because … (you should
> complete this sentence).
> * Fix up packages and tell package names I should not touch because you did
> that already.
> * Tell package
Hi,
With valgrind-3.13.0-15.fc28 the valgrind-devel package only contains
the development headers needed for building valgrind aware applications.
So it only contains the stand alone headers valgrind.h, callgrind.h,
drd.h, helgrind.h and memcheck.h that have the client request macros
that give hi
On Mon, 2018-01-22 at 08:38 +, Tomasz Kłoczko wrote:
> Effectively Fedora has not to much from relation with RH *between*
> major EL releases in form of straight contribution to Fedora constant
> changes. They may be sending back some fixes done for RHEL customers
> but that is all. However as
On Sat, Jan 20, 2018 at 12:27:38PM +0100, Igor Gnatenko wrote:
> Why I'm writing this? I want to hear from you if you think it would be
> good to prohibit (or advise, or whatever mechanism would work) usage if
> conditionals in (at least) master branch to allow us to develop features
> faster. Thou
On Thu, 2018-01-11 at 11:21 +0100, Patrick Monnerat wrote:
> I also encountered this problem before and I fixed it by respecting
> the
> RPM_OPT_FLAGS. Before cmake, use:
>
> export CFLAGS="${RPM_OPT_FLAGS}"
> export CXXFLAGS="${RPM_OPT_FLAGS}"
>
> This did the trick.
>
> Obviously the problem
Hi Richard,
On Sat, 2018-01-06 at 11:27 +, Richard W.M. Jones wrote:
> I noticed as a side effect of compiling GCC for riscv64 that RISC-V's
> GCC doesn't support -fstack-clash-protection. Do you know what is
> involved to add it? From a naive point of view I don't understand
> why this feat
1 - 100 of 167 matches
Mail list logo
