Hi,
Review Request: icemon - A GUI monitor for Icecream
https://bugzilla.redhat.com/show_bug.cgi?id=1965529
Spec URL: http://people.redhat.com/jkratoch/icemon.spec
SRPM URL: http://people.redhat.com/jkratoch/icemon-3.3-6.fc34.src.rpm
It should be very simple IMO, it is an unretirement.
Thanks,
On Mon, 28 Sep 2020 17:58:58 +0200, Jakub Jelinek wrote:
> 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:
> > > A way out of this could be either to use comdat .debug_info etc. sections
> >
On Wed, 07 Oct 2020 09:58:37 +0200, Jan Kratochvil wrote:
> On Wed, 07 Oct 2020 00:46:24 +0200, Jeff Law wrote:
> > On 9/30/20 3:50 AM, Jan Kratochvil wrote:
> > > When we start talking about RHEL (and CentOS) DWZ is completely pointless
> > > then
> &g
On Wed, 07 Oct 2020 00:46:24 +0200, 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 ha
On Mon, 05 Oct 2020 09:20:53 +0200, Florian Weimer wrote:
> Fedora Server still defaults to LVM and XFS, as far as I know. I expect
> that downstream will continue to use XFS as well.
>
> I don't think you can assume that debugging information will be stored
> on btrfs file systems.
OK. Then
On Mon, 05 Oct 2020 08:28:03 +0200, Florian Weimer wrote:
> Why do you think that? Using debuginfo for perf and the like seems to
> be much more common than actual debugging, based on what I see
> downstream.
OK, interesting, thanks for the info. Still that does not change anything with
btrfs
On Tue, 29 Sep 2020 22:29:44 +0200, Mark Wielaard wrote:
> I was just discussing that recently with the Hotspot Perf GUI
> maintainer. And we concluded that if .debug files would be compressed
> then we would need an uncompressed cache somewhere. The issue with
> having the on-disk debuginfo files
On Mon, 28 Sep 2020 16:51:02 +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
On Fri, 02 Oct 2020 18:11:45 +0200, Jan Kratochvil wrote:
> On Wed, 30 Sep 2020 15:58:51 +0200, Stephen John Smoogen wrote:
> > On Wed, 30 Sep 2020 at 09:41, Jan Kratochvil
> > wrote:
> > > On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote:
> &g
On Wed, 30 Sep 2020 23:42:56 +0200, Michel Alexandre Salim wrote:
> On Mon, 2020-09-28 at 16:50 +0200, Jan Kratochvil wrote:
> > For example during Fedora Package Review Process do some packages get
> > rejected because they would make the distribution too large? Not worth o
On Wed, 30 Sep 2020 15:58:51 +0200, Stephen John Smoogen wrote:
> On Wed, 30 Sep 2020 at 09:41, Jan Kratochvil
> wrote:
> > On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote:
> > > = What I am NOT working on
> > [...]
> > > - Any other tool,
On Wed, 30 Sep 2020 14:50:39 +0200, Mark Wielaard wrote:
> = What I am NOT working on
[...]
> - Any other tool, project not mentioned above or other
> native toolchains like golang, rust, clang/llvm or ocaml.
> I expect those to simply keep producing DWARF4.
So because of a DWZ deficiency you
On Tue, 29 Sep 2020 22:31:28 +0200, Mark Wielaard wrote:
> Note that you are using -ffunction-sections together with -flto.
> With -flto you don't need -ffunction-sections.
>
> -ffunction sections might cause functions to be dropped by the linker
> without updating the DWARF DIEs, causing things
On Tue, 29 Sep 2020 22:35:14 +0200, Mark Wielaard wrote:
> On Mon, Sep 28, 2020 at 04:50:59PM +0200, Jan Kratochvil wrote:
> > * DW_TAG_partial_unit should have DW_AT_language.
> > * DW_TAG_partial_unit must contain only types (struct/class).
> >Currently they contain fo
On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote:
> -fdebug-types-section a supported option in the sense that it's in the
> compiler and we'll fix bugs in it when we can. But the GCC community
> doesn't really test that option and it's known to be broken with LTO.
I believe you base this
On Fri, 25 Sep 2020 16:29:26 +0200, Jan Kratochvil wrote:
> On Fri, 25 Sep 2020 12:10:22 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > I would love to see a comparison of numbers for three things:
> > - raw debuginfo without dwz or -fdebug-types-section
>
> Oops, I do not ha
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 -fdebug-types-section being broken with LTO.
During one abigail diff I did not see any difference. I plan to run a
On Wed, 30 Sep 2020 10:44:06 +0200, Jakub Jelinek wrote:
> On Wed, Sep 30, 2020 at 10:33:59AM +0200, Jan Kratochvil wrote:
> > Because doing it separately like GDB does is a wrong thing for
> > edit-compile-debug cycle. When clang (lld for LTO) has all the data incl. IR
> &
On Wed, 30 Sep 2020 02:00:52 +0200, Michel Alexandre Salim wrote:
> On Tue, 2020-09-29 at 16:29 -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/DebugInfoLldbIndex
> > Currently the change will affect only packages using:
> > %global toolchain clang
> > Those are currently only
On Wed, 30 Sep 2020 10:14:55 +0200, Jakub Jelinek wrote:
> it would be great if the
> .debug_names some tool generates (whether it is GDB, some standalone
> post-linking (and post dwz) tool, dwz itself, ...) is usable by both GDB and
> LLDB, because the point in DWARF5 standardizing .debug_names
On Wed, 30 Sep 2020 02:11:34 +0200, Neal Gompa wrote:
> Why don't you add an lldb-add-index tool to generate LLVM indexes for
> LLDB?
Because doing it separately like GDB does is a wrong thing for
edit-compile-debug cycle. When clang (lld for LTO) has all the data incl. IR
already in memory it
On Mon, 28 Sep 2020 17:58:58 +0200, Jakub Jelinek wrote:
> On Mon, Sep 28, 2020 at 05:46:08PM +0200, Jan Kratochvil wrote:
> > https://whova.com/embedded/session/llvm_202010/1193947/
>
> If you do it on the compiler side, you'll get a lot of those pesky partial
> units you s
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 -mtune=generic -march=x86-64
-g -g -g -O2 -O2 -O2 -O2 -fno-openmp
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
> reduction,
I am ignoring the on-disk size, I always measure just *-debuginfo.rpm size.
If anyone
On Mon, 28 Sep 2020 12:42:33 +0200, Jakub Jelinek wrote:
> On Mon, Sep 28, 2020 at 12:31:59PM +0200, Mark Wielaard wrote:
> > Finally I am interested in your proposal to implement a different way
> > to reduce the size of DIE trees by eliminating "unused" DIEs. It is
> > hard to predict what
On Mon, 28 Sep 2020 12:31:59 +0200, Mark Wielaard wrote:
> If you want to make -fdebug-types-sections the default you really
> should work with the upstream GCC developers to figure out why they
> don't want that.
I haven't seen that, according to Richard Biener from GCC
-fdebug-types-section is
On Mon, 28 Sep 2020 14:08:48 +0200, Mark Wielaard wrote:
> It is certainly a clever setup and makes sense if your build bottleneck
> is sending files around between different machines. But I don't think
> this is the generic Fedora packager or developer use case.
I agree and I do not propose
On Fri, 25 Sep 2020 16:29:26 +0200, Jan Kratochvil wrote:
> On Fri, 25 Sep 2020 12:10:22 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> > - debuginfo with dwz (current approach)
>
> rpm size: 35186079102
> disk size: 177913332940
>
> > - debuginfo with -fdebug-t
On Fri, 25 Sep 2020 17:40:50 +0200, Florian Weimer wrote:
> The numbers are very difficult understand because it's not clear what
> you are measuring. Especially since as far I understand it, parts are
> not yet fully implemented, so we can't know yet if all the required data
> is there.
TL;DR
On Fri, 25 Sep 2020 17:09:54 +0200, Robbie Harwood wrote:
> So saying "Google does it" (or similar) is *not* a good argument.
So let's stick only to the numbers I sent in other mails.
In fact I do not understand why we talk about anything except the numbers.
Jan
On Fri, 25 Sep 2020 12:10:22 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> I'm missing some good statistics.
I have 1.6TB of statistics, ask me anything. It is calculated by my scripts:
https://git.jankratochvil.net/?p=massrebuild.git;a=tree
git clone
On Fri, 25 Sep 2020 13:43:40 +0200, Neal Gompa wrote:
> On Fri, Sep 25, 2020 at 7:26 AM Ryan wrote:
> >
> > > == Benefit to Fedora ==
> > > * Better compatibility with existing debugging and tracing tools,
> > > primarily [https://lldb.llvm.org/ LLDB].
> >
> > Thanks for your work on this Ben and
On Fri, 25 Sep 2020 13:56:47 +0200, Jakub Jelinek wrote:
> Jan had probably problems getting his DWZ support upstreamed into LLDB
It isn't completely easy, I have already upstreamed a lot of preparatory work
for the DWZ patchset which is good for LLDB in general.
Just before upstreaming the
On Fri, 25 Sep 2020 07:08:27 +0200, Dominique Martinet wrote:
> Jan Kratochvil wrote on Thu, Sep 24, 2020:
> > Copy-pasted it at the bottom of this mail. I do not know the talk but TL;DR
> > existing DWARF contains some dead DIEs - unused/deduplicated functions and
> > a
On Fri, 25 Sep 2020 11:36:47 +0200, Mark Wielaard wrote:
> On Thu, Sep 24, 2020 at 08:34:48PM +0200, Jan Kratochvil wrote:
> > error: Allocatable section after non-allocatable ones
> > https://sourceware.org/bugzilla/show_bug.cgi?id=24251#c10
>
> That isn't a
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
> works correctly with GCC11 if it switches to producing DWARF5 by
> default.
The problem is
On Fri, 25 Sep 2020 11:01:53 +0200, Neal Gompa wrote:
> On Fri, Sep 25, 2020 at 3:08 AM Florian Weimer wrote:
> > This is not a -dbgsym package, so it probably has been created by a
> > different procedure. I do not know how Ubuntu distributes their -dbgsym
> > packages. An example from Debian
On Thu, 24 Sep 2020 20:04:22 +0200, Stephen John Smoogen wrote:
> The original language of the proposal said no other distribution used DWZ,
> and that the format was not adopted and should be removed.
I have already updated the Wiki in the meantime based on new information from
this list:
On Thu, 24 Sep 2020 20:10:45 +0200, Neal Gompa wrote:
> I do not feel that this is a valid premise either, since the reason
> for no dwz support in LLDB is because nobody contributed it.
> I'm slightly surprised that Red Hat's debuginfo engineers hadn't already
> contributed support for it into
On Thu, 24 Sep 2020 19:16:32 +0200, Neal Gompa wrote:
> Then that certainly means that Ubuntu uses this too, since they reuse
> the dbgsym subpackage generation for the ddeb system they have now.
I am not much familiar with Debian/Ubuntu but I cannot find any use of DWZ
there:
On Thu, 24 Sep 2020 19:01:17 +0200, Neal Gompa wrote:
> This is not true. Debian started producing -dbgsym packages and
> putting them in a separate repository years ago:
> https://wiki.debian.org/AutomaticDebugPackages
>
> dwz is used by virtually all RPM based distributions now, including
>
On Mon, 13 Jul 2020 18:32:10 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> gdb-9.2-2.fc33.x86_64 which is the latest rawhide build... Does gdb need
> updating?
You may rather ask at gdb -at - sourceware.org.
Jan
___
devel mailing list --
On Sat, 11 Jul 2020 16:52:41 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> warning: Unexpected size of section `.reg-xstate/59286' in core file.
> #0 0x7f552f8b3b95 in raise () from /lib64/libc.so.6
> (gdb)
>
> Is this gcc, gdb, binutils, something else?
gdb is older than kernel and you have
On Fri, 10 Jul 2020 20:05:07 +0200, Kevin Fenzi wrote:
> Perhaps a compromise could be to generate them for rawhide builds, but
> not stable releases and if someone needs to debug things ask them to use
> the rawhide one/debuginfo?
That is not useful, system debuginfos are there to catch bugs
On Tue, 07 Jul 2020 21:11:31 +0200, Kevin Fenzi wrote:
> I am not sure what to tell you here. Perhaps you could describe the
> reason you are working on the chromium debuginfo? Is it broken? Missing?
> Less useful that normal?
Missing. Completely.
And it is not just about enabling it (=remove
On Fri, 03 Jul 2020 14:52:00 +0200, Jan Kratochvil wrote:
> On Thu, 02 Jul 2020 02:04:48 +0200, Kevin Fenzi wrote:
> > On Wed, Jul 01, 2020 at 11:22:26PM +0200, Jan Kratochvil wrote:
> > > I will file a ticket after Spot says his opinion (or not).
> >
> > Sure.
>
On Thu, 02 Jul 2020 02:04:48 +0200, Kevin Fenzi wrote:
> On Wed, Jul 01, 2020 at 11:22:26PM +0200, Jan Kratochvil wrote:
> > I will file a ticket after Spot says his opinion (or not).
>
> Sure.
https://src.fedoraproject.org/rpms/chromium/
On Thu, 02 Jul 2020 02:04:48 +0200, Kevin Fenzi wrote:
> I have fixed the buildhw-x86 boxes, they all now have ~365GB now.
Yes, it has built fine:
https://koji.fedoraproject.org/koji/taskinfo?taskID=46455864
> Sorry, I misunderstood you... I thought you were wanting to test a
> scratch
On Wed, 01 Jul 2020 17:46:23 +0200, Kevin Fenzi wrote:
> * Is this only on x86_64 that you need this? Or all arches?
Sure we should have this on all arches but I haven't tested non-x86_64 yet.
There possibly may be also some memory problems even on x86_64 (it builds on
my machine w/64GB but Koji
On Wed, 01 Jul 2020 15:14:09 +0200, Stephen John Smoogen wrote:
> At the moment we have about 10% of the hardware
> we shipped back in operation and there are at least 2 to 3 weeks to
> get the rest up. Getting up larger builders is going to have to wait.
Sure there is no hurry with larger
On Wed, 01 Jul 2020 13:43:57 +0200, Stephen John Smoogen wrote:
> In the end we have limited resources and you are running into those
> limits. We can either have fewer builders with more disk space and a
> long queue of builds or we can have more builders with smaller disk
> space.
Good to know
Hi,
I have tried to enable debuginfo for Chromium but it cannot fit the disk.
During local build it has 160GB (on x86_64) and Koji shows (moreover AFAIK
shared for multiple builders):
https://kojipkgs.fedoraproject.org//work/tasks/7099/46377099/hw_info.log
Filesystem Size
On Fri, 26 Jun 2020 10:23:31 +0200, Iñaki Ucar wrote:
> On Fri, 26 Jun 2020 at 10:20, Leigh Scott wrote:
> > Please don't make this universal for all the spins, it should be optional.
> > TBH I don't give a damn if you do it to the workstation spin, please keep
> > your grubby hands off the
On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:
> On 6/26/20 12:42 AM, Jan Kratochvil wrote:
> > This will be always a catch up play. To make it working each completion
> > script
> > would need to be part of the package it is implementing completion for.
> >
On Fri, 26 Jun 2020 09:40:32 +0200, Samuel Sieb wrote:
> That's only if you start vi without a file. Otherwise, you just get the
> text of the file on the screen and the bottom line with the filename and
> cursor position. No info at all about what just happened.
OK, I agree. So what about
On Fri, 26 Jun 2020 09:36:05 +0200, Samuel Sieb wrote:
> Is this something that happens to you often?
It was happening often on an Athlon computer which I retired recently.
So no longer.
Or rather it still happens for me (X1 carbon 6th with docking station) but
during switching to X when the
On Fri, 26 Jun 2020 09:38:06 +0200, Samuel Sieb wrote:
> On 6/26/20 12:27 AM, Jan Kratochvil wrote:
> > Some replies also do not like this change, I am not alone. Still it looks
> > like
> > there area really more votes for this change than against it. Fine with me.
>
>
On Fri, 26 Jun 2020 03:31:10 +0200, Samuel Sieb wrote:
> But regardless, that's something to fix in the dnf bash completion scripts,
> not a reason to completely disable completion as the earlier poster said.
TL;DR it regresses the original bash completion feature.
This will be always a catch up
On Fri, 26 Jun 2020 01:34:19 +0200, Samuel Sieb wrote:
> I agree with your points, but pressing ESC only reverses the "rhgb" part,
> the kernel output is still "quiet".
If the kernel really locks up it is locked up and no keys work anymore.
Without "rhgb quiet" one can make a photo of the screen.
On Fri, 26 Jun 2020 02:25:24 +0200, Matthew Miller wrote:
> But, if you don't like our offerings that are targetted that way, I suggest
> you make a spin or remix that has all of defaults _you_ want.
So FESCo has decided and there is no point of discussing this Change, that is
how it will be and
On Fri, 26 Jun 2020 03:48:56 +0200, Adam Williamson wrote:
> 3. provides a handy reference of key combos you can use to get help,
> save the file, and exit. Yes, you have to know that ^O means "ctrl+O",
> but figuring that out is a lot easier than working out how to drive vi
> from scratch.
After
On Thu, 25 Jun 2020 21:58:28 +0200, Jonathan Wakely wrote:
> try 'ls $HOME/' without the direxpand
> option set, and tell me what on earth that is for.
It works as expected, what is the problem? Using ctrl-e instead of direxpand
but keeping there $HOME/ may be what one wants.
> the only thing I
On Thu, 25 Jun 2020 21:21:37 +0200, Chris Adams wrote:
> I'm not sure why you think end-users can't use a free OS.
First steps of end-users is to install Chrome, Spotify and VirtualBox.
So there is left no advantage of a Free OS.
> I've run with SELinux enabled for years, rarely if ever causes
On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
> In contrast, Nano offers the kind of graphical text editing experience
> that people are used to,
This is another step trying to make Fedora end-user friendly while the only
effect is making it hostile to developers. As Fedora will never be
On Sun, 07 Jun 2020 17:22:33 +0200, Barry Scott wrote:
> python3-debuginfo.x86_64 3.8.3-1.fc32
>
> @updates-debuginfo
...
> Reading symbols from /usr/bin/python3.8...
> Reading symbols from .gnu_debugdata for /usr/bin/python3.8...
> (No debugging
On Sat, 13 Jun 2020 22:10:36 +0200, Pierre-Yves Chibon wrote:
> jkratoch
This account is set as "inactive" in FAS. Couldn't you regenerate this list
with inactive accounts excluded?
I would like to remove this old account but FAS admin interface cannot do
that, I can only set it as "inactive".
On Sat, 30 May 2020 00:58:26 +0200, Chris Murphy wrote:
> The Fedora Workstation working group recognizes hibernation can be
> useful, but due to impediments it's currently not practical to support
> it.
TL;DR let's go the s2idle way as that is the only one which may work. But for
me it resumes
On Sun, 24 May 2020 05:21:05 +0200, Paul Dufresne via devel wrote:
> The idea was to push code generation as near as possible of code execution.
> Because at execution time, you know what are the specific features of the
> CPU, and what is used to most often by the user of the program.
In Free
On Fri, 17 Apr 2020 06:55:10 +0200, Michel Alexandre Salim wrote:
> For kernel updates this is probably not a good idea. Given that updates
> potentially introduce regressions, being able to distinguish updates with
> known CVEs that we do need to roll out immediately, versus other updates we
>
On Mon, 13 Apr 2020 18:43:07 +0200, Tom Callaway wrote:
> The linker said: error adding symbols: Malformed archive. Searching leads
> me to translate that error to "too many open files". See:
> https://github.com/OSSystems/meta-browser/issues/194
>
> Apparently, gold does not have this issue, but
On Fri, 03 Jan 2020 22:45:52 +0100, Neal Gompa wrote:
> Can someone please explain why gdb dlopen()'s librpm instead of just
> doing proper compile-time linking?
Because when it was written (2008) it was common to transfer /usr/bin/gdb
binary across OS versions (maybe incl. RHEL) as GDB had only
On Mon, 30 Dec 2019 00:58:24 +0100, Michael Cronenworth wrote:
> warning: Could not find DWO CU
> CMakeFiles/kodi-xrandr.dir/xbmc-xrandr.c.dwo(0xc444049b4814c563) referenced
> by CU at offset 0x0 [in module
> /builddir/build/BUILDROOT/kodi-18.5-1.fc32.x86_64/usr/lib64/kodi/kodi-xrandr]
Unaware
On Thu, 19 Dec 2019 22:42:02 +0100, Ben Cotton wrote:
> == Summary ==
> Enabling fstrim.timer will cause fstrim.service to execute weekly,
> which in turn executes `/usr/sbin/fstrim --fstab --verbose --quiet`
This is AFAIK not enough for LUKS drives, will it be supported for LUKS?
Jan
On Mon, 25 Nov 2019 22:59:18 +0100, Samuel Sieb wrote:
> I don't understand why this change is
> necessary at all. It only affects local logins and if someone wants to have
> an empty password, why make it so difficult? It's their choice. It's not
> like Fedora has any default logins with empty
On Thu, 07 Nov 2019 22:36:44 +0100, Jan Kratochvil wrote:
> On Thu, 07 Nov 2019 15:59:41 +0100, Victor Stinner wrote:
> > I cannot explain why inlining cannot be done more often in libpython.
> >
> > I cannot explain why PLT is needed when a libpython function calls a
&
On Thu, 07 Nov 2019 15:59:41 +0100, Victor Stinner wrote:
> I cannot explain why inlining cannot be done more often in libpython.
>
> I cannot explain why PLT is needed when a libpython function calls a
> libpython function.
Could you re-run the benchmark with shared library but with
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 hit for dynamically linked Python?
Yes, it looks suspicious. -fPIC was a
On Thu, 05 Sep 2019 14:43:48 +0200, Stephen Gallagher wrote:
> This isn't required, no. That being said, if this package is abandoned
> upstream then it probably makes sense to contact the Debian maintainer
> and establish a fork where our projects can at least share patches. If
> upstream comes
On Mon, 02 Sep 2019 23:33:32 +0200, Richard W.M. Jones wrote:
> On Sun, Sep 01, 2019 at 09:33:29PM +0200, Jan Kratochvil wrote:
> > Fix stack overflow in: `inotifytools_replace_filename`
> > https://bugzilla.redhat.com/show_bug.cgi?id=1741472
> >
> > Not sure h
Hi,
Fix stack overflow in: `inotifytools_replace_filename`
https://bugzilla.redhat.com/show_bug.cgi?id=1741472
Not sure how to fix this crashing bug. Upstream is dead while Fedora package
maintainer requires to upstream the fix first. A Catch 22.
Debian has the crasher fixed by an off-trunk
On Sun, 11 Aug 2019 20:54:28 +0200, Chris Murphy wrote:
> and likely experiences data loss and possibly even file system
> corruption as a direct consequence of having to force power off on the
> machine because for all practical purposes normal control has been
> lost.
Not really, this is what
On Sun, 11 Aug 2019 17:50:17 +0200, Chris Murphy wrote:
> I don't follow. You're saying RelWithDebInfo is never suitable for a
> local build?
Most of the time. What is your use case for it?
> isn't relevant to getting a successful build.
With powerful enough machine everything is possible.
On Fri, 09 Aug 2019 23:50:43 +0200, Chris Murphy wrote:
> $ cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
RelWithDebInfo is -O2 -g build. That is not suitable for debugging, for
debugging you should use -DCMAKE_BUILD_TYPE=Debug (that is -g).
RelWithDebInfo is useful for final rpm
On Thu, 06 Dec 2018 11:59:35 +0100, Germano Massullo wrote:
> This seems to not happen with Valgrind
I would first suggest using compiler option -fsanitize=address instead of
valgrind.
Jan Kratochvil
___
devel mailing list -- de
On Wed, 08 Aug 2018 02:11:08 +0200, Andrey Ponomarenko wrote:
> 2) The -get-inventory-id option creates a new inventory id (or 'group') to
> mark new probes by this id. You've created too many inventory ids per day
> and received an error when trying to create more. Usually it's enough to
> have
e
# hw-probe -inventory-id 0xbf0a7f04b4
# hw-probe -get-inventory-id
Group ID: 7b448de5
# hw-probe -get-inventory-id
Error request
# hw-probe -get-inventory-id
Error request
Jan Kratochvil
__
On Mon, 06 Aug 2018 17:30:02 +0200, David Malcolm wrote:
> On Mon, 2018-08-06 at 13:15 +0200, Jan Kratochvil wrote:
> > That confirms the whole OS "Checked Build" variant would solve even this
> > problem.
>
> Jan: In my view, it's not a problem, it's a feature
On Mon, 06 Aug 2018 10:57:31 +0200, Petr Viktorin wrote:
> On 08/05/18 14:01, Jan Kratochvil wrote:
> > That is all together messy. This is why Microsoft has their debug build of
> > their whole OS - Windows - called Checked Build:
> >
> > https://docs.microsoft
On Sun, 05 Aug 2018 14:47:06 +0200, Andrey Ponomarenko wrote:
> I've just created Fedora package for hw-probe. See
> https://github.com/linuxhw/hw-probe/blob/master/INSTALL.md#install-on-fedora.
Installing a package out of repository for its maintenance is not great.
I tried to find a repository
On Sun, 05 Aug 2018 13:39:58 +0200, Charalampos Stratakis wrote:
> Here we are referring to the python2-debug or python3-debug builds, which
> are just extra python builds that are compiled with the --with-pydebug flag
Not just --with-pydebug:
On Thu, 26 Jul 2018 21:14:14 +0200, Carlos O'Donell wrote:
> Bug 1430223 - In some conditions, tcmalloc memalign will segfault
> https://bugzilla.redhat.com/show_bug.cgi?id=1430223
It looks as a tcmalloc bug which could be fixed; it also has been probably
fixed in the meantime as stated there.
On Thu, 26 Jul 2018 17:43:06 +0200, Daniel P. Berrangé wrote:
> # dnf repoquery --whatrequires 'libjemalloc.so.2()(64bit)'
> 389-ds-base-devel-0:1.4.0.11-2.fc28.x86_64
> blender-1:2.79b-2.fc28.x86_64
> blender-1:2.79b-3.fc28.x86_64
> blenderplayer-1:2.79b-2.fc28.x86_64
>
here are two orthogonal languages, C and C++.
(And some people say C++11 and C++03 are also orthogonal.)
Jan Kratochvil
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Co
On Wed, 04 Jul 2018 12:18:00 +0200, Zbigniew Jędrzejewski-Szmek wrote:
> What about just doing a mass specfile update now? I think asking
> individual maintainers to fix their packages isn't worth their
> time. It's a safe change,
Is it? I haven't found whether this change is compatible with
On Thu, 01 Mar 2018 19:30:28 +0100, Pierre-Yves Chibon wrote:
> On Fri, Feb 16, 2018 at 03:04:11PM +0100, Jan Kratochvil wrote:
> > On Fri, 16 Feb 2018 11:02:25 +0100, Pierre-Yves Chibon wrote:
> > It seems to me interactive crash core file analysis is just not a goal of
>
On Fri, 16 Feb 2018 11:02:25 +0100, Pierre-Yves Chibon wrote:
> So what do you advice as course of action here, should we fix darkserver or
> move
> its functionality to ABRT?
"move its functionality to ABRT"
> The later is tempting to me if it's just a few lines of code added on an app
> we
On Wed, 14 Feb 2018 11:02:52 +0100, Pierre-Yves Chibon wrote:
> If there is little interest for this project, we will likely decommission it
> in
> the coming weeks (say end of March).
The darkserver project ws initiated AFAIK by me as there is always a problem
how to reproduce an ABRT
On Wed, 14 Feb 2018 15:55:20 +0100, Pierre-Yves Chibon wrote:
> darkserver itself doesn't store anything.
Darkserver was at least in the past using debuginfo storage from ABRT server
which is much more rich than what Koji server keeps.
Jan
___
devel
On Sun, 04 Feb 2018 22:14:47 +0100, Doug Ledford wrote:
> cc1: fatal error: inaccessible plugin file plugin/annobin.so expanded
> from short plugin name annobin: No such file or directory
...
> So, where is the gcc plugin annobin?
In my fresh Rawhide buildroot
On Sun, 10 Dec 2017 13:43:25 +0100, Richard Shaw wrote:
> I pretty much did the same thing with valgrind but the output of your
> script is much more concise and easier to read.
Fedora GDB should print the dnf debuginfo-install command. When it does not?
It uses a similar script logic
1 - 100 of 360 matches
Mail list logo
