Re: gdb says "Unexpected size of section `.reg-xstate/...` in core file

2020-07-13 Thread Jan Kratochvil
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 --

Re: gdb says "Unexpected size of section `.reg-xstate/...` in core file

2020-07-13 Thread Jan Kratochvil
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

Re: out of Koji disk space

2020-07-11 Thread Jan Kratochvil
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

Re: out of Koji disk space

2020-07-09 Thread Jan Kratochvil
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

Re: out of Koji disk space

2020-07-06 Thread Jan Kratochvil
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. >

Re: out of Koji disk space

2020-07-03 Thread Jan Kratochvil
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/

Re: out of Koji disk space

2020-07-03 Thread Jan Kratochvil
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

Re: out of Koji disk space

2020-07-01 Thread Jan Kratochvil
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

Re: out of Koji disk space

2020-07-01 Thread Jan Kratochvil
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

Re: out of Koji disk space

2020-07-01 Thread Jan Kratochvil
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

out of Koji disk space

2020-07-01 Thread Jan Kratochvil
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Jan Kratochvil
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Jan Kratochvil
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. > >

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Jan Kratochvil
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Jan Kratochvil
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Jan Kratochvil
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. > >

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Jan Kratochvil
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Jan Kratochvil
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.

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Jan Kratochvil
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Jan Kratochvil
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-25 Thread Jan Kratochvil
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-25 Thread Jan Kratochvil
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

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

2020-06-25 Thread Jan Kratochvil
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

Re: It seems that gdb cannot find debuginfo on f32

2020-06-14 Thread Jan Kratochvil
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

Re: Packagers with no corresponding valid bugzilla accounts

2020-06-14 Thread Jan Kratochvil
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".

Re: Supporting hibernation in Workstation ed., draft 1

2020-05-30 Thread Jan Kratochvil
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

Re: late generation of assemble code

2020-05-26 Thread Jan Kratochvil
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

Re: Getting security updates out to users sooner

2020-04-17 Thread Jan Kratochvil
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 >

Re: The Chromium Dilemma

2020-04-14 Thread Jan Kratochvil
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

Re: Why does gdb dlopen() librpm instead of linking to it?

2020-01-03 Thread Jan Kratochvil
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

Re: Gcc/annobin changes in F32

2019-12-30 Thread Jan Kratochvil
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

fstrim and LUKS [Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default]

2019-12-20 Thread Jan Kratochvil
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

Re: Fedora 32 System-Wide Change proposal: Disallow Empty Password By Default

2019-11-25 Thread Jan Kratochvil
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

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

2019-11-07 Thread Jan Kratochvil
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 &

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

2019-11-07 Thread Jan Kratochvil
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

Re: Fedora 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

2019-11-06 Thread Jan Kratochvil
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

Re: inotify-tools with dead upstream cannot be fixed in Fedora

2019-09-05 Thread Jan Kratochvil
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

Re: inotify-tools with dead upstream cannot be fixed in Fedora

2019-09-04 Thread Jan Kratochvil
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

inotify-tools with dead upstream cannot be fixed in Fedora

2019-09-01 Thread Jan Kratochvil
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

Re: Better interactivity in low-memory situations

2019-08-11 Thread Jan Kratochvil
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

Re: Better interactivity in low-memory situations

2019-08-11 Thread Jan Kratochvil
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.

Re: Better interactivity in low-memory situations

2019-08-10 Thread Jan Kratochvil
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

Re: Valgrind and Fedora debuginfo: best GUI

2018-12-06 Thread Jan Kratochvil
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

Re: Reliability test for hard drives and SSD

2018-08-08 Thread Jan Kratochvil
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

Re: Reliability test for hard drives and SSD

2018-08-07 Thread Jan Kratochvil
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 __

Re: Why are we shipping debug builds of pythons?

2018-08-06 Thread 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

Re: Why are we shipping debug builds of pythons?

2018-08-06 Thread Jan Kratochvil
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

Re: Reliability test for hard drives and SSD

2018-08-05 Thread Jan Kratochvil
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

Re: Why are we shipping debug builds of pythons?

2018-08-05 Thread Jan Kratochvil
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:

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

2018-07-27 Thread Jan Kratochvil
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.

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

2018-07-27 Thread Jan Kratochvil
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 >

Re: [HEADS UP] Removal of GCC from the buildroot

2018-07-11 Thread Jan Kratochvil
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

Re: Packages which needlessly use %defattr

2018-07-04 Thread Jan Kratochvil
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

Re: Call for users of darkserver

2018-03-02 Thread Jan Kratochvil
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 >

Re: Call for users of darkserver

2018-02-16 Thread Jan Kratochvil
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

Re: Call for users of darkserver

2018-02-14 Thread Jan Kratochvil
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

Re: Call for users of darkserver

2018-02-14 Thread Jan Kratochvil
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

Re: Rawhide buildroot broken?

2018-02-04 Thread Jan Kratochvil
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

Re: gdb: No symbol table info available

2017-12-10 Thread Jan Kratochvil
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

Re: gdb: No symbol table info available

2017-12-09 Thread Jan Kratochvil
On Sat, 09 Dec 2017 20:42:46 +0100, Richard Shaw wrote: > Any tips? A correct backtrace would have replaced your line #10 0x in ?? () with line #10 0x0040043a in _start () but otherwise everything would be all the same. Tips in general for segfaults are valgrind. Or

Re: gdb: No symbol table info available

2017-12-09 Thread Jan Kratochvil
On Sat, 09 Dec 2017 19:13:24 +0100, Richard Shaw wrote: > #9 0x7621f891 in __libc_start_main (main=0x0, argc=0, argv=0x0, > init=, fini=, rtld_fini=, > stack_end=0x0) at ../csu/libc-start.c:329 > result = > unwind_buf = {cancel_jmp_buf = {{jmp_buf = {4309931, 0,

Re: remote X connections

2017-11-30 Thread Jan Kratochvil
On Thu, 30 Nov 2017 13:39:16 +0100, Christian Groessler wrote: > This is handled by conditional compilation in gdm (depending on a > HAVE_XSERVER_THAT_DEFAULTS_TO_LOCAL_ONLY define). gdm ignores DisallowTCP=false on F22 https://bugzilla.redhat.com/show_bug.cgi?id=1226084 FYI I had a problem with

Re: Call for testing - Firefox 57

2017-11-17 Thread Jan Kratochvil
On Fri, 17 Nov 2017 19:53:43 +0100, Randy Barlow wrote: > On 11/16/2017 11:50 PM, Adam Williamson wrote: > > (I don't understand why we package Firefox addons at all, it seems like > > a silly idea. But oh well.) > > I personally like the idea of packaging addons, for the same reasons I > like

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

2017-08-24 Thread Jan Kratochvil
On Thu, 24 Aug 2017 21:51:59 +0200, Sandro Mani wrote: > May well be mistaken, but doesn't ABRT work with coredumps, which you can't > get on Windows systems? OK, thanks for showing me the setup. I was still imagining running PE32 binaries by Wine, I did not realize there exist real Windows

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

2017-08-24 Thread Jan Kratochvil
On Thu, 24 Aug 2017 21:36:29 +0200, Sandro Mani wrote: > While I'm at it, my current technique for interpreting mingw stacktraces > produced without debuginfos is parsing the text and calling addr2line for > each stack frame. Is there a neater technique? Unaware of. But then why you do not have

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

2017-08-24 Thread Jan Kratochvil
On Thu, 24 Aug 2017 14:31:11 +0200, Sandro Mani wrote: > On 24.08.2017 14:18, Jan Kratochvil wrote: > > On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote: > > > I'm investigating why gdb returns so unreliable backtraces for mingw > > > binaries without debugin

Re: mingw-find-debuginfo.sh: objcopy strip-unneeded vs strip-debug?

2017-08-24 Thread Jan Kratochvil
On Thu, 24 Aug 2017 13:43:32 +0200, Sandro Mani wrote: > I'm investigating why gdb returns so unreliable backtraces for mingw > binaries without debuginfos, They are perfectly reliable. They just do not show the function names. But those can be looked up later from *-debuginfo.rpm. ... >

Re: debuginfo/source improvements vs mass rebuild

2017-08-12 Thread Jan Kratochvil
On Mon, 31 Jul 2017 13:16:29 +0200, Mark Wielaard wrote: > - Putting extra files under /usr/lib/debug causes: > error: Installed (but unpackaged) file(s) found: > > /usr/lib/debug/usr/lib64/__pycache__/libpython3.6dm.so.1.0.debug-gdb.cpython-36.opt-1.pyc > >

Re: Starting an x86_32 SIG

2017-07-12 Thread Jan Kratochvil
On Wed, 12 Jul 2017 20:32:57 +0200, Stephen John Smoogen wrote: > 2. A formal statement as requested by some users about the architecture > 3. A survey of problems on the architecture. > 4. A hardware selection the SIG are going to focus on. > 5. What product the SIG is planning to deliver. Just

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift) [resent]

2017-03-17 Thread Jan Kratochvil
On Fri, 17 Mar 2017 15:40:34 +0100, Tomasz Kłoczko wrote: > (Resending below as looks like I've replied only to Jan) also resending On Fri, 17 Mar 2017 06:18:56 +0100, Tomasz Kłoczko wrote: > I saw already such tweaks in many Fedora specs %check sections. > IMO such %ifing inside or around

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

2017-03-17 Thread Jan Kratochvil
On Fri, 17 Mar 2017 06:18:56 +0100, Tomasz Kłoczko wrote: > I saw already such tweaks in many Fedora specs %check sections. > IMO such %ifing inside or around %check is incorrect/not needed and can be > removed. > Why? Because: > - all possible to use package tests should be by default enabled > -

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

2017-03-16 Thread Jan Kratochvil
On Thu, 16 Mar 2017 01:32:06 +0100, Tomasz Kłoczko wrote: > OK here is full list of spec files which have glibc-static in BuildRequires: > > ./g/gdb.git/gdb.spec:BuildRequires: glibc-static%{bits_local} This is a false positive as it is enclosed by: %if 0%{?_with_testsuite:1} I have no

Re: overriding CXX_FLAGS

2017-01-24 Thread Jan Kratochvil
On Tue, 24 Jan 2017 10:54:32 +0100, Mattia Verga wrote: > I must ask developers why they recommend to use c++11 and then they set it > fixed to gnu++11 gnu++11 is a superset of c++11 so that should work either. Older GCCs defaulted to c++98, they may mean the project requires compiler

Re: Bluetooth headsets vs rawhide

2017-01-22 Thread Jan Kratochvil
On Mon, 23 Jan 2017 00:52:07 +0100, Kevin Fenzi wrote: > If I switch them to HSP/HFP I get no > audio in or out. Apps that try and use them just hang. linphone sometimes hangs for me so I have to fix it by: # rm -f /usr/bin/pulseaudio;killall pulseaudio Without that 'rm' pulseaudio just

Re: debuginfo updates: RFE for dnf?

2017-01-13 Thread Jan Kratochvil
On Fri, 13 Jan 2017 19:26:16 +0100, Przemek Klosowski wrote: > Are you saying that currently it updates them completely independently? Yes. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: debuginfo updates: RFE for dnf?

2017-01-13 Thread Jan Kratochvil
On Fri, 13 Jan 2017 18:16:18 +0100, Stephen Gallagher wrote: > Probably because debuginfo files are very large and you might not want to > waste > bandwidth keeping them updated. (Just guessing here) Also the repos are commonly out of sync so some packages have N+1 binary rpm while other

Re: Decompress debug-info compressed by dwz

2016-12-27 Thread Jan Kratochvil
On Tue, 27 Dec 2016 13:27:02 +0100, Andrey Ponomarenko wrote: > Hello, Is there a way to decompress the > debug-info compressed by dwz? The issue is that all > compile units in the DWARF dump may depend on each other in the compressed > debug-info and they can't be analyzed independently for this

Re: Creating cores in f25

2016-12-18 Thread Jan Kratochvil
On Sun, 18 Dec 2016 17:26:40 +0100, Steve Dickson wrote: > How do I get f25 to create cores, these days? echo >/etc/sysctl.d/foo.conf "kernel.core_pattern=core"; reboot It gets broken by: /usr/lib/sysctl.d/50-coredump.conf $ rpm -qf /usr/lib/sysctl.d/50-coredump.conf

Re: dnf should not update debuginfo if not updating packgages

2016-11-05 Thread Jan Kratochvil
On Sat, 05 Nov 2016 05:20:10 +0100, Kevin Kofler wrote: > Because -debuginfo is per SRPM, not per subpackage, so you can need the > -debuginfo without having all subpackages (or even the main package) > installed. There could be for example: Conflicts: %{name} != %{version}-%{release} But that

Re: Critpath flags on Emacs and Guile

2016-10-21 Thread Jan Kratochvil
On Fri, 21 Oct 2016 13:18:38 +0200, Peter Robinson wrote: > guild would be because it's a dep of a dep of gdb-headless guile libguile-2.0.so.22 is DT_NEEDED - as shown by ldd. Easy way would be to make gdb-headless a separate binary/build. Less easy way would be to dlopen() libguile from gdb

Re: GDB: Recommends vs. Suggests and abrt->gdb->gcc dependency

2016-09-12 Thread Jan Kratochvil
Hi Jakub, On Mon, 12 Sep 2016 09:57:24 +0200, Jakub Filak wrote: > However, I thinking we can resolve this issue on packaging level. We just > need to introduce a new package shipping the core gdb functionality and make > ABRT dependent on it. The new package should not ship /usr/bin/gdb but

GDB: Recommends vs. Suggests and abrt->gdb->gcc dependency

2016-09-10 Thread Jan Kratochvil
Hi, there have been submitted these Bugs: Drop the gcc dependency https://bugzilla.redhat.com/show_bug.cgi?id=1195005 gdb pulls in devel packages (gcc, kernel-headers, etc.) [former Summary] https://bugzilla.redhat.com/show_bug.cgi?id=1306591 due to recent GDBs

Re: Show warnings from a C/C++ build

2016-07-15 Thread Jan Kratochvil
On Fri, 15 Jul 2016 22:46:23 +0200, Jerry James wrote: > Attached is a little script I use when doing a mock build with gcc or > g++, to see what warnings the compiler emitted. I usually ignore > -Wunused* warnings, as those aren't usually dangerous, but I pay > attention to -Wstrict-aliasing,

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Jan Kratochvil
On Thu, 30 Jun 2016 16:13:59 +0200, Josh Boyer wrote: > On Thu, Jun 30, 2016 at 9:53 AM, Jan Kratochvil <jan.kratoch...@redhat.com> > wrote: > > But now there is ppc64le for >=Power8. So <=Power7 can use ppc64 but newer > >>=Power8 hardware does use ppc64le

Re: multi-CPU optimization inside a distribution

2016-06-30 Thread Jan Kratochvil
On Thu, 30 Jun 2016 12:12:37 +0200, Dan Horák wrote: > For ppc64 (the big endian POWER) the base is set by the toolchain > default which is Power4/ppc970. When Power7 came we were asked what are > the options to take the advantage of these CPUs, 3 generations newer > than the base. The solution

Re: Hacks for multilib unclean C headers

2016-06-07 Thread Jan Kratochvil
find the separate .h files for each arch only as a last resort hack. And thus I find it not preferred to make a last resort hack a part of the standard packaging macros. Jan Kratochvil (*) Why not - it would be probably rejected upstream as too "new"; although this patch also was

Re: Firefox not working anymore over ssh?

2016-04-02 Thread Jan Kratochvil
On Sat, 02 Apr 2016 09:39:33 +0200, drago01 wrote: > On Sat, Apr 2, 2016 at 9:26 AM, Samuel Sieb wrote: > > On 04/02/2016 12:20 AM, drago01 wrote: > >> Also XWayland only supports DRI3; > > > > You say it's currently fixed by falling back to DRI2, but then you say that > > DRI2

Re: Firefox not working anymore over ssh?

2016-04-01 Thread Jan Kratochvil
On Tue, 29 Mar 2016 19:22:31 +0200, Tim Landscheidt wrote: > Michael Catanzaro wrote: > > Then it was probably broken by this update: > > > https://bodhi.fedoraproject.org/updates/FEDORA-2016-606ca05253 > > The "LIBGL_DRI3_DISABLE=1" workaround fixed it for me as > well

Re: IPv6 application test suite – call for participation

2016-03-21 Thread Jan Kratochvil
to add '--allowerasing' to command line to replace conflicting packages) on Fedora 23 x86_64 Jan Kratochvil -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: hawkey replaced by libhif, DNF into C initiative started

2016-02-25 Thread Jan Kratochvil
On Thu, 25 Feb 2016 18:03:52 +0100, David Malcolm wrote: > I think I'm only semi-serious here [1], but have you considered Rust? > [1] e.g. it's not yet in Fedora. or proven C++11(/14/17)? (it is already in Fedora) Jan -- devel mailing list devel@lists.fedoraproject.org

Re: Couldn't find DIE referenced by DW_OP_GNU_implicit_pointer

2016-02-24 Thread Jan Kratochvil
On Wed, 24 Feb 2016 17:59:29 +0100, Sérgio Basto wrote: > Hello, > What $subject means ? , should I be worried ?  > > Only happens in rawhide , I think is GCC6 warning.   Google found that message in: https://ppisar.fedorapeople.org/perl_rebuild/scratch/latest/packages/perl-version/build.log

Re: GCC 6 -Wnonnull is too aggressive

2016-02-19 Thread Jan Kratochvil
On Fri, 19 Feb 2016 13:07:53 +0100, Ralf Corsepius wrote: > But I say, there should not be any room for -Werror in production > SW/packages. > > The fact, > * different version of gcc raise different warnings > * gcc on different architectures raise different warnings. > * gcc raises warnings on

Re: GCC 6 -Wnonnull is too aggressive

2016-02-17 Thread Jan Kratochvil
On Wed, 17 Feb 2016 18:25:29 +0100, Ralf Corsepius wrote: > Remove -Werror. [...] > -Werror is useful to devs when actively working on code, but using it in > released production code to be used in packages is plain st***. -Werror has found me many times bugs in Fedora add-on patches not being up

Re: Debugging practices and hardened packages

2016-01-25 Thread Jan Kratochvil
On Mon, 25 Jan 2016 19:16:33 +0100, Kevin Fenzi wrote: > so you could well have an update that isn't the current one that has no > debuginfo on mirrors, but you could always get it from koji. If you have only a core file you know build-ids dumped there but not NVRAs. build-id -> NVRA mapping was

Re: Debugging practices and hardened packages

2016-01-25 Thread Jan Kratochvil
On Mon, 25 Jan 2016 18:12:44 +0100, Roman Tsisyk wrote: > How long debuginfo packages are stored in repositories? > For example, someone may have an old version of package for which debuginfo > already has gone. > How to debug in this case? ABRT retrace server has some storage and infrastructure

Re: Should 'dnf install gtk3-devel.i686' work?

2016-01-21 Thread Jan Kratochvil
On Thu, 21 Jan 2016 16:37:01 +0100, Jonathan Wakely wrote: > A developer who wants to build a 32-bit program on x86_64 might not > be in the mock group. Their system administrator might not want to Aren't the multiuser systems a history now with VPSes or even just containers cheaper than a

Re: Should 'dnf install gtk3-devel.i686' work?

2016-01-21 Thread Jan Kratochvil
On Thu, 21 Jan 2016 23:24:13 +0100, Ian Malone wrote: > and shifting data in and out is more awkward than working directly on it. Mock has bind_mount* plugin for that. Jan -- devel mailing list devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

2016-01-20 Thread Jan Kratochvil
On Wed, 20 Jan 2016 23:59:01 +0100, Michael Schwendt wrote: > On Wed, 20 Jan 2016 21:59:01 +0100, Jan Kratochvil wrote: > > On Wed, 20 Jan 2016 16:50:03 +0100, Richard W.M. Jones wrote: > > > However on the same host if you do: > > > > > > dnf install gtk3-

Re: Should 'dnf install gtk3-devel.i686' work?

2016-01-20 Thread Jan Kratochvil
On Wed, 20 Jan 2016 16:50:03 +0100, Richard W.M. Jones wrote: > However on the same host if you do: > > dnf install gtk3-devel.i686 > > then there's a lot missing before you can compile a 32 bit Gtk3 > application[2]. There were always missing many %{?_isa} in BuildRequires, I was filing many

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

2016-01-15 Thread Jan Kratochvil
On Fri, 15 Jan 2016 09:42:17 +0100, Dan Horák wrote: > On Fri, 15 Jan 2016 09:24:36 +0100 Tomáš Smetana wrote: > > On Wed, 13 Jan 2016 14:38:08 +0100 Florian Festi wrote: > > I tend to use systemd-nspawn containers for building rpms. So for > > example, I

  1   2   3   4   >