Re: Calling autoconf in a spec.

Adam Williamson writes: > [...] >> > There's a big difference between having the upstream, who knows their >> > configure script inside and out, >> >> That's a very bold assertion. ;-) Many upstream developers just copy&paste >> their configure.ac scripts together [...] > > Yeah, autotools stu

Re: Why EDID is not trustworthy for DPI

Adam Williamson writes: > [...] > But that's still going to require some kind of sensible handling of the > case where one monitor is roughly 100dpi and the other is roughly > 200dpi, unless we simply say 'you can't do that, all your displays have > to be in the same DPI Category'. Perhaps the s

Re: UsrMove feature

=?ISO-8859-2?Q?Micha=B3_Piotrowski?= writes: > [...] > What is wrong with > #!/usr/bin/env interpreter > from technical POV? It's more wordy. It makes it impossible to pass an interpreter argument. It will execute slower. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin

Re: ABRT unusable again

Michael Schwendt writes: >> I believe ABRT shouldn't file a bug report unless it is filled in >> properly. > > Yeah, some of us have pointed out that before. > I'm happy about every detailed backtrace I get, but I would be even more > happy if users contributed a tiny bit more and added comments

Re: ABRT unusable again

Jiri Moskovcak writes: > Such log would be nice, but it might take some time (even days) before > the app crashes again and I can imagine that could generate quite a > large log :-/ Maybe if it would store just last few syscalls... Sure, some circular logging, the last few thousand syscalls, no

Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

James Antill writes: > [...] > Probably the saddest thing about this giant flamewar you've started is > [...] For what it's worth, I have seen no lack of courtesy from Kevin Kofler in this thread, so the accusation of "flamewarism" would be more appropriately directed to those who have not kept

Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

"Nicolas Mailhot" writes: > Clearly, bohdi/bugzilla/pk interaction is not good enough to collect > the kind of feedback needed for the karma system to work. And bohdi > should get smarter about identifying packages that need this > feedback. Critical path is a good first approximation but what wo

Re: Fight bugs, not FESCo

Bruno Wolff III writes: > A couple of problems. Which packages are downloaded from mirrors is not > currently available to Fedora. [...] Would it be crazy to reorganize the mirror system in such a way that normally download http requests come to fedoraproject.org, but are redirected at the http-

Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

Peter Jones writes: > [...] You weren't elected "FESCo Monitor"; the guy who comes and > tells the mailing list whenever FESCo is discussing something you > think is scary. [...] One need not be "elected" to do that. Anyone reading the public fesco irc logs may do the same without special disp

Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

James Antill writes: > https://fedoraproject.org/wiki/Release_Lifecycle_Proposals#Choice_.28james.29 Regarding this, I don't understand this part: > The idea behind this proposal is that a Fedora user installing a > release N has a lot of choice if they wish to get newer packages: > > * The

Re: Bodhi karma feature request

Panu Matilainen writes: > [...] > Oh yes. Even just a big red REGRESSION button that stops the update from > automatically entering stable no matter what the karma votes happen to be > would be a definite improvement. [...] Just for completeness, please let's be cautious about giving knobs to

Re: FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

James Antill writes: >> > [...] >> > ...but they have almost no options if they are happy to stay with >> > the software that they have. >> >> Doesn't "just not running random/unrestricted yum update" exactly >> encode that option? > > No, for two reasons: > > 1. The user is often informed, fr

Re: Announcing `gold-rebuild' - link your packages with gold now

Michal Nowak writes: > Past months I spent investigating `gold' - the new GNU linker > and how it now works with stock Fedora packages. > [...] Do your scripts provide some evidence of exciting speedups with gold? - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedorap

Re: grub2 and setting crashkernel kernel argument

Roman Rakus writes: > How are fedora with grub2 users supposed to set up crashkernel kernel > argument? [...] Does GRUB_CMDLINE_LINUX="crashkernel=auto" in /etc/default/grub work, followed by grub2-mkconfig? - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraprojec

Re: F15 Feature - convert as many service init files as possible to the native SystemD services

Miloslav =?UTF-8?Q?Trma=C4=8D?= writes: > [...] If the system integrates everything into one process, the > only remaining troubleshooting mechanisms are integrated logging > [...], debugger [...] and systemtap (only a little better than a > debugger, and not available for most programs). To c

Re: [HEADS-UP] Moving /var/run and /var/lock to tmpfs in Rawhide

Daniel J Walsh writes: > [...] > So if you create a directory in the postinstall of an rpm, the directory > will be created as var_run_t (rule 1), rpm has SELinux intelligence > built in, but since you did this in postinstall, rpm command does not > know you did it. You will have to run restor

Re: SSD support in Anaconda/F14

Ric Wheeler writes: > [...] Various drives perform better or worse with file system, fine > grained discard support so not all will see a performance hit. Could the system run benchmarks to determine whether its own drives fall into this category? - FChE -- devel mailing list devel@lists.fedo

heads-up: systemtap-sdt-devel rebase in rawhide

Hi - FYI, rawhide received a new build of systemtap-1.4 yesterday. (f13 and f14 may get it too, subject to update policy & interest). Beyond its direct users, it affects those packages that build with the markers. A subsequent rebuild of these will switch to the new implementation. It should

Re: Removing -fexceptions from $RPM_OPT_FLAGS

Pierre-Yves writes: > [...] > I have been looking into the review #668863 in which the packager for > this library (who also happens to be upstream) is actually removing the > flag "-fexceptions" from $RPM_OPT_FLAGS in the %build. > [...] > - Upstream does not want to have this flag on, saying t

Re: Removing -fexceptions from $RPM_OPT_FLAGS

Tom Lane writes: > Hmm ... so what should I do with mysql? Since approximately forever, > upstream has recommended using -fno-exceptions (and also > -felide-constructors -fno-rtti) in CXXFLAGS. [...] -fexceptions / -frtti are essentially harmless, so I am curious why they were ever thought to

Re: heads-up: systemtap-sdt-devel rebase in rawhide

tgl wrote: > [...] I think the only near-term fix is to turn off dtrace support > in mysql. [...] We'll do one better; we'll add a hack to sys/sdt.h to make mysql build and respin systemtap today or tomorrow. > But the real issue here is that systemtap has got to be more chary of > what they

Re: use MALLOC_PERTURB_ ... or lose

Jeff Spaleta writes: > [...] >> Stating something like this clearly on login & install would be nice, >> not just for this MALLOC_PERTURB_ change but in general. > > Doesn't this whole discussion about debugging versus performance also > apply to F13 pre-release testing as well.. and not just raw

Re: Increase grub timeout

Matthew Garrett writes: > [...] >> [...] But still, the sensible path is to make >> reasonable accommodations for this sort of thing. Let's face it, if >> we're waiting on Sony or HP to fix this, we'll be waiting a while. > Or, alternatively, we can actually look into the problem and determine

Re: moderated/held messages on mailing lists

writes: > It has nothing to do with disk space. Sitting on a few hundred > thousand spam messages for no reason, that'll get ignored forever, > and that slow mailman down, serves no purpose. But why would there be so many spam messages in need of manual moderation? Surely there is a spam filte

Re: debuginfo for sub packages (Help with RPM SPEC files)

Roland McGrath writes: > It's normal to get a single foo-debuginfo package from a foo.src.rpm. > Please explain exactly why this is a problem for you. One possible reason is RPM-level conflicts between concurrently installed multilib debuginfo RPMs, such as glibc.i686 and glibc.x86_64. - FChE -

Re: Bug 531464 - why the WONTFIX?

Kevin Kofler writes: > [...] > Actually, I think WONTFIX is a bad choice of resolution here, UPSTREAM or, > in the specific case of the reporter refusing to file an upstream bug, > INSUFFICIENT_DATA is IMHO a better choice. ... or FEDORA_MAINTAINER_PATCH_ROBOT_TOO_BUSY. - FChE -- devel maili

activating services by default, definition of network sockets

Hi - I have a question about [1], the policy limiting what services may be started/enabled by default (when the RPM is installed). # If a service does not require configuration to be functional and # does not listen on a network socket, it may be enabled by default # [...] # All other s

Re: Join to Mozilla Location Service in Fedora

stransky wrote: > [...] I'd like to ask you to join the project, install the Mozilla > Stumbler application [3] and help to improve the location > accuracy. [...] Until Mozilla figures out how to publish this data [1], it seems premature to ask us to donate to it. [1] https://location.services

Re: [Guidelines change] Changes to the packaging guidelines

Jason L Tibbitts III writes: > Here are the recent changes to the packaging guidelines: > [...] > * https://fedoraproject.org/wiki/Packaging:DefaultServices > [...] In this context (1.1 "locally running services"), what is a "public network socket"? Is the idea that localhost services are now

Re: [Guidelines change] Changes to the packaging guidelines

sgallagh wrote: > [...] > The definition of "public" was intentionally vague, but perhaps we > could try to find a better way to say it. I was trying to treat it as > "network interfaces that accept connections from arbitrary sources". OK ... > I'm not sure that there's a tremendously meaningfu

Re: [Guidelines change] Changes to the packaging guidelines

zbyszek wrote: > [...] > Clarification: this change did not touch this part of the policy: that > definition got copied over from the guidelines [1]. [...] (The previous wording said a package that "...does not listen on a network socket..." can be enabled by default, which was a broader restric

Re: [Guidelines change] Changes to the packaging guidelines

sgallagh wrote: > [...] Yes, I thought my new phrasing was more clearly expressing > the original intent of the statement as I understood it. [...] I > think we should perhaps discuss this at the weekly FESCo meeting. https://fedorahosted.org/fesco/ticket/1446 > This is what I get for trying

Re: libmicrohttpd / gnutls / openvas

Reindl Harald writes: > "libmicrohttpd" seems to be broken due gnutls changes and > was not rebuilt for decades as also the autotests are > disabled in the src.rpm [...] > i see also in the (few) fedora-openvas packages > "disable gnutls pacth, enable gnutls patch" multiple times While libmicro

Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?

John Reiser writes: > [...] > According to this bugzilla Comment >https://bugzilla.redhat.com/show_bug.cgi?id=786878#c27 > Fedora 17 Alpha turned on denyPtrace (as default) by mistake. That's not how I read #c27. The flag was turned off during alpha by mistake and that it would be on in the

Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?

dwalsh wrote: > I thought I made this clear in my blogs and the feature page that I wanted > this on deny_ptrace on by default. > [...] > https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace The version of this page that you last edited [1] (and presumably as seen by FESCO) had this blurb:

Re: SELinuxDenyPtrace: Write, compile, run, but don't debug applications?

dwalsh wrote: > [...] deny_ptrace will be DISABLED for F17. Already checked in. [...] Note that the selinux-policy rpm update that corrects this has not yet been pushed to any yum update/-testing channels. It would be a shame if the f17 beta spin went out with this bug. https://admin.fedorapr

Re: sudo and changes in packaging guidelines

> [...] > If your package meets the following criteria you MUST enable the PIE compiler > flags: > [...] > * Your package runs as root. > [...] If this is meant to cover administrative binaries that have no privilege escalation pieces of their own, merely run by root, then what makes them diffe

Re: sudo and changes in packaging guidelines

ajax wrote: > [...] >> If this is meant to cover administrative binaries that have no >> privilege escalation pieces of their own, merely run by root, then >> what makes them different from any other /bin/* program that a root >> process might invoke? > > It's not meant to cover that. That phras

Re: disruptive libffi upgrade

"Horst H. von Brand" writes: > [...] > Please go with (3), keeping generated files in git is just dumb. Please don't demean those who do it for well-considered reasons. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

kevin.kofler wrote: > [...] There is no room left on the KDE live image for installing > any sort of debugging information by default. [...] What are the live-image spins' plans as to management of future growth? At what point, if ever, do they intend to abandon the CD-ROM format limits? - FC

Re: Proposed F18 feature: MiniDebugInfo

notting wrote: > [...] > 2) "It will also make it easier to do things like system wide profiling, > userspace dynamic probes and causual debugging." > > However, the Scope: is only gdb and rpm. Wouldn't said tools also need > changes? Would this be done in libdwarf, or similar? > [...] Profiling

Re: x32 abi support?

mjg59 wrote: > [...] If you have any applications that need to be 64-bit (ie, > anything that is going to need more than 4GB of address space, which > is very different from needing more than 4GB of RAM) then you need > to have two copies of your libraries and suddenly your memory > benefits hav

Re: x32 abi support?

drago01 writes: > [...] Can x32 run i686 software (multilib) ? Because not being > able to run existing software might be a reason for many to want > such a host. x32 is not a different cpu architecture. It's a software ABI to run on x86-64, especially suited for smaller-memory machines/proce

Re: x32 abi support?

Tomasz Torcz writes: > [...] Can we get some definite numbers? Yeah, not enough of those going around. A quick test with systemtap, a typical pointer/datastructure-heavy program, on same x86-64 machine, compiled with -m64 and -m32, same workload. It parses /proc/self/statm. 64-bit ./stap -p

Re: How to proceed with MiniDebugInfo

jan.kratochvil wrote: > If your feature does not solve any problem it is just a bloat. This overstates the case. Alex's proposal clearly solves some problems. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default file system, was: Comparison to Workstation Technical Specification

Chris Murphy writes: > > Okay, I'll bite. Why not rootfs on raid6? > It's pathological. Sick? Non-functional? Unlucky? > There are too many simpler, faster, more resilient options > considering rootfs at most isn't bigger than the average SSD: Two or > three SSDs + n-way mirroring. RAID 10

Re: Summary/Minutes from today's FESCo Meeting (2014-03-05)

sgallagh wrote: >> Seriously? Retiring useful package? Isn't that a bit of >> overkill? (Yes, I'm grumpy because I'm using Cherokee). > > This has been discussed ad nauseam. > > The reasoning was that upstream ships imagery that is in violation of > Fedora's policy not to ship offensive materia

Re: default local DNS caching name server

william wrote: > [...] > Internal and external zone views in a business. These records may > different, and so would need flushing between network interface state > changes. Sure, let's make it easy to restart the cache upon such transitions. > Additionally, local DNS caches may issues and dela

Re: F21 Self Contained Change: Remote Journal Logging

Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= writes: > [...] Using HTTP makes it possible to use e.g. use curl to upload > some logs from the commandline. It should also be fairly easy for > people to write e.g. Python code to upload logs. [...] Are you envisioning these journal files being cre

Re: The Forgotten "F": A Tale of Fedora's Foundations

sgallagh wrote: > [...] > > Sometimes this goal prevents us from taking the easy way out by > > including proprietary or patent encumbered software in Fedora, or > > using those kinds of products in our other project work. [...] > > The language in this Foundation is sometimes dangerously unclear

Re: Automatically generated configuration files

Paul Wouters writes: > [...] > How many packages would actually perform any kind of "opportunistic > encryption"? I know the mail servers prefer a selfsigned cert over no > cert whatsoever, but what other applications have this issue of "better > unknown certificate than plaintext" ? Probably al

Re: Anyone have any idea why apps are starting to search /proc/sys/vm?

dwalsh writes: > [only the $subject] # stap -e 'probe syscall.open { if(substr(filename,0,5) == "/proc") { println(pid(), " ", execname(), " ", filename) print_ubacktrace() } }' -d /usr/lib*/libc-*.so (Repeat with more -d /usr/bin/foo as stap advises.) - FChE -- devel mailing

Re: LibRaw: possible license issues

Debarshi Ray writes: > [...] You don't think that it is a problem that our downstreams > might inadvertently end up violating the GPL by shipping GPLv3 code > that links to non-free software? [...] It is not *our* problem. - FChE -- devel mailing list devel@lists.fedoraproject.org https://adm

Re: F20 System Wide Change: ARM as primary Architecture

Adam Williamson writes: > [...] "Primary Architectures : These are architectures with the > majority of the users, the most common architectures. [...] By that standard, PA treatment of ARM seems way premature. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedorapro

Re: F20 System Wide Change: No Default Syslog

Lennart Poettering writes: > [...] >> How about this idea. Before "No Defualt Syslog", systemd needs to >> completely replicate all functionality provided by syslog, including >> /var/log/messages, by default. Syslog emulation would be an option, and if >> people don't want it, they can still t

Re: F20 System Wide Change: No Default Sendmail

mattdm wrote: > [...] > What does it mean to "have available"? As discussed earlier, I think it's > significantly better for applications to get errors (which they can handle) > than to think they've sent a message which really gets buried forever. There exist /usr/lib/sendmail submission-only i

Re: RFC: Proposal for a more agile "Fedora.next" (draft of my Flock talk)

Remi Collet wrote: > [...] Ex : I'm so disgusted that I don't ever have desire to read > the rest of the doc. Please don't - that part is easily renamed ("Fedora Kernel", or "Fedora Standard Base" or "Fedora Platform" or something) if people are still offended by some aspect of the the core/ext

Re: F20 System Wide Change: Enable kdump on secureboot machines

vgoyal wrote: > [...] >> Have you considered a non-cryptographic solution, like a physical >> presence check to (temporarily) disable Secure Boot so that the >> kexec restriction no longer applies? [...] > > I think kyle has a patch which will allow disabling secureboot > restriction if one is o

Re: F20 System Wide Change: No Default Sendmail

Lennart Poettering writes: > [...] essentially boils down to "I hate change". Which is an OK > opinion to have, but certainly not four Fedora, where the four Fs > mean "Freedom, Friends, Features, First". The "First" indicates that > we should be pioneers, and *not* the guys who never change bec

Re: What does it mean if two debuginfo packages create the same dwz build ID file?

"Richard W.M. Jones" writes: > [...] So in summary, is this a bug in how I'm building debuginfo > files or a bug in the debuginfo generation or something else? It's more the latter than the former. Your debuginfo files lack something that for other C builds would set them apart, perhaps some r

Re: Reminder on how to EOL a package

Dennis Gilmore writes: > [...] Also please note that you are not to Retire packages for > stable Fedora's [...] Can this be mechanically enforced? - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://f

Re: yum groupinstall development-tools FAILS

Philip Rhoades writes: > [...] > yum --exclude=systemtap-sdt-devel* groupinstall development-tools > still gives the same errors . . How about a "yum update systemtap\*" first? - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

>> > [...] I always run dnf manually from the >> > command line, in a VT logged in as root. And I can run X while doing >> > this and I've never had a dnf update issue. To the extent that the problem is that dnf gets interrupted when its xterm dies, can that be worked around by dnf SIG_IGN'ing

Re: Thoughts on SystemTap, Perf and LTTng ?

Hi Davide - dblistsub-fedora wrote: > [...] I am considering using one of the above to see if they can > usefully substitute the practice of peppering code with tracing > statements (logging or performance analysis are not the focus). As I > would be a beginner in any of them, I was curious ab

Re: BuildRequires for texlive stuff for F18 and beyond

Hi - jonathan.underwood wrote: > [...] > With the more fine grained texlive packaging in F>18 where tex(latex) is > provided by texlive-collection-latex I am finding that this is insufficient to > build most documents. I see two options in these cases: > > 1) Add BuildRequires; texlive-collectio

Re: Proposed F19 Feature: Fedora Upgrade - using yum

Simo Sorce writes: > [...] B) I will *not* trust an update system that cuts me out of my > remote server and make me *hope* it will come up later. If yum > freaks out for *whatever* reason I want to be there with an > emergency shell open [...] I've been saved more than once by a > shell open d

Re: BuildRequires for texlive stuff for F18 and beyond

Jindrich Novy writes: > [...] Just to be clear here, we are talking about BuildRequires of > packages, not end-user TeX compilation here. > If end-user utilization is needed then feel free to use > texlive-collection* or texlive-scheme*. Another least overhead > option is to just install: texli

Re: Results of a test mass rebuild of rawhide/x86_64 with gcc-5.0.0-0.5.fc22

Marek Polacek writes: > To get some sense on how is GCC 5 standing, we (myself and Jakub > Jelinek) have performed a test mass rebuild of rawhide (January 15th > package list) using gcc-5.0.0-0.5.fc22 on x86_64 [...] I'd like to bring to folks' attention one other scenario that can bite with a g

Re: MongoDB Security & Defaults

"Ryan S. Brown" writes: > [...] In January, the Fedora rawhide package for mongo[2] was > changed to listen on all interfaces by default [...] To help > protect users, I think the default should be changed back to > localhost only. [...] We have a slew of network-servers in the fedora distribu

Re: Is rpmbuild reentrant?

Neil Horman writes: > [...] > Um, no. All I was suggesting was that you build the package tests separately > from the package itself, as its own rpm. You can put multiple source tarballs into a single rpm, build each of them in your spec %build/etc., and result in distinct subrpms. Is that not

Re: kmods and Fedora

Bastien Nocera writes: >> > If you are creating a cert to sign the out-of-tree modules and expect >> > it to be accepted by the kernel, it cannot be ephemeral. A user would >> > need someway to import it into their kernel or have it passed from >> > grub. [...] >> >> That just proves that Rest

Re: Diagreement with pkgconfig removal

praiskup wrote: > [...] > Cool. Let's provide 'pkgconf' so we can be also three, too! But at the > same time please consider not dropping 'pkgconfig' for no reason. ... and also let's make sure that the new package does not break builds. For one of ours, the .spec file contained: BuildRequire

Re: CPE Git Forge Decision

> [...] Nor would it have helped with the SLA requirements and > operational cost. [...] What reason is there to believe that a gitlab commercial SaaS might a smaller operational cost? - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To u

Re: CPE Git Forge Decision

> > [...] Nor would it have helped with the SLA requirements and > > operational cost. [...] > What reason is there to believe that a gitlab commercial SaaS > might a smaller operational cost? > I meant that in the sense of the time we invest in it to develop > features, fix bugs

Re: debuginfod non-standard-uid and cache permissions

Hi - > These are all done deliberately through the following constructs in the spec > file: > > In %pre to create the debuginfod user: > >getent group debuginfod >/dev/null || groupadd -r debuginfod >getent passwd debuginfod >/dev/null || \ >useradd -r -g debuginfod -d /var/cach

Re: Red Hat & Fedora -- largely stepping out of this ecosystem

Jeff Law writes: > [...] > First a bit of background. I came to Red Hat via the Cygnus > acquisition. [...] > > One could see signs of where this was going with the adjustments that > were made to the exposed RHEL kernel sources some time ago. Then the > dissolution of CentOS a couple years b

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

Michael Catanzaro writes: > [...] > Please, stop saying this. It's just not true. All Fedora users will > benefit from the performance improvements that we're able to make > using sysprof. [...] Then perhaps the Change could have had a dead-man-switch built in: unless performance improvements du

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

Michael Catanzaro writes: >> Then perhaps the Change could have had a dead-man-switch built in: >> unless performance improvements due to this profiling change do not in >> fact appear by F39 or F40, the Change should be automatically >> reverted. > > Question is how to measure that? Is it suffic

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

> Of course, but the benefit is to fix performance bugs in applications > or maybe the desktop itself. [...] >> Let's be firm in testing this empirically rather than aspirationally. > I really don't know how. Suggestions welcome. I'd put the onus on the proponents of the Change, who made predict

Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)

Hi - > The thing is that perf + flamegraphs makes your whole system much more > visible and so it's much easier to find these kind of gains in > specific scenarios. (There are exist other profiling tools and techniques that do not require frame pointer recompilation, but whatever.) > Frame poi

Re: FESCo revote on "Add -fno-omit-frame-pointer" Change proposal [was Re: Schedule for Tuesday's FESCo Meeting (2023-01-03)]

Matthew Miller writes: > So, from a purely "what are the rules?" view, the Change process says: > FESCo will vote to approve or deny a change proposal in accordance with > the FESCo ticket policy. > > ... and I won't quote all of that, but looking at > https://docs.fedoraproject.org/en-US/fes

IMA testing, Re: Fedora Linux 37 Beta Released

bcotton wrote: > [...] > ## Beta Release Highlights > [...] > # RPM content is now signed with IMA signatures How can one observe this? Even with rpm-plugin-ima installed, steps in: https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents#How_To_Test produce no output for any of the files I

Re: F38 proposal: PostgreSQL 15 (Self-Contained Change proposal)

Ben Cotton writes: > https://fedoraproject.org/wiki/Changes/PostgreSQL_15 >[...] > === Plan === > > * Prepare PostgreSQL 15 in Copr (TBD) > * Rebuild important dependencies in Copr (TBD) > * Debug and fix compatibility issues found in dependencies (a > reasonable amount of non-critical in FTBFS s

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

Demi Marie Obenour writes: > Three other options I can think of: > [...] Another one: 4. Speed up out-of-context backtracer(s), possibly consuming kernel-perf-ringbuffer stack dumps, or possibly using another event source to trigger and work via ptrace and /proc/$pid/mem - FChE ___

Re: Smaller buildroot for Perl packages

Hi - > [...] > > My idea is to split systemtap-sdt-devel into two packages: one with all the > > content but without the python script (/usr/bin/dtrace) and a new one > > containing only the mentioned script. No objection here. > > [...] > > I also did a test rebuild of all packages directly b

Re: Smaller buildroot for Perl packages

Hi - > > > > I also did a test rebuild of all packages directly build-requiring > > > > systemtap-sdt-devel and identified these packages that really need the > > > > dtrace script: [...] > > (The logistic challenge there will be side-tag rebuilding all those > > after a systemtap subrpm split.) >

Re: Smaller buildroot for Perl packages

Hi - > > OK, build-time dependency changes may not need the side tag but do > > need a spec update to prevent a FTBFS at next build. > > Only those packages that actually need dtrace would require changes. Such > changes could land gradually as needed. They'd have to land at the next respin of e

Re: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

Hi, Denys - dvlasenk wrote: > [...] > Now readelf, annobin and hell knows what else started to talk to > REMOTE SERVERS, deep out of internals of complicated build infrastructure > running on presumably secure build machines of various IT corporations > and whatnot! (It may not be appropriate

Re: F41 Change Proposal: Switch to DNF5 (system-wide)

Jan Kolarik writes: >[...] > The dnf-automatic command will still be available, now provided as a > plugin and functionally compatible with dnf4. Although the > configuration files' location has changed, it will be documented in > the dnf4 vs. dnf5 changes documentation. This configuration file

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

> https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer > [...] > === Unwinding === > [...] > * Kernel 4.8 frame pointer benchmarks by Suse showed 5%-10% > regressions in some benchmarks > (https://lore.kernel.org/all/20170602104048.jkkzssljsompj...@suse.de/T/#u) Regressions of such magni

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

> [...] > What Meta is doing can indeed only reasonably be done with a sampling > profiler, with additional restrictions (in particular, they state that > Perf's support to drop back to userspace for DWARF unwinding is too slow for > them) [...] (Note FWIW that systemtap's kernel runtime does

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

demiobenour wrote: >> (Note FWIW that systemtap's kernel runtime does DWARF-based unwinding >> for the kernel and user-designated userspace executables and >> shared-libraries on demand, and it's not particularly slow at it.) > > How does it do that? Does it have a kernel-mode DWARF unwinder? Y

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

>> Yes, but this approach is unlikely to be adopted there. > Why is this? I do not have any extra information beyond what is on the LKML record. - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

Michael Catanzaro writes: > I can point you to documentation for sysprof: > https://gitlab.gnome.org/GNOME/sysprof#debugging-symbols > which says that every library should be built with > -fno-omit-frame-pointer. Given that sysprof is a userspace program, it's not in a giant rush, so it should b

Re: F37 proposal: Add -fno-omit-frame-pointer to default compilation flags (System-Wide Change proposal)

ngompa13 wrote: > [...] > I agree, this is a completely unacceptable statement to make. The > problem isn't sysprof, the problem is that profiling is garbage on > Linux by default. That's an overstatement. > And while maybe most developers may not bother to do profiling right > now, we don't kn

interest in debuginfod as fedora service

Hi - If you never use debuggers, tracing tools, profilers, crash dump analysis tools, go ahead and skip this note! If you're still reading, you know you sometimes need debuginfo for the packages you're working with. And you probably know that % sudo debuginfo-install is still the official w

Re: interest in debuginfod as fedora service

Adam Williamson writes: > This seems like it sort of overlaps a bit with what the abrt retrace > server does. It's not the same, but in order to do what it does, the > retrace server *does* need to act as a remote provider of debuginfo. I > wonder if it's possible to combine these somehow? As I

Re: interest in debuginfod as fedora service

Adam Williamson writes: > This seems like it sort of overlaps a bit with what the abrt retrace > server does. It's not the same, but in order to do what it does, the > retrace server *does* need to act as a remote provider of debuginfo. I > wonder if it's possible to combine these somehow? Anoth

Re: F28 System Wide Change: Deprecate TCP wrappers

jkurik wrote: > [...] > https://fedoraproject.org/wiki/Changes/Deprecate_TCP_wrappers > > TCP wrappers is a simple tool to block incoming connection on > application level. This was very useful 20 years ago, when there were > no firewalls in Linux. This is not the case for today and connection >

Re: [atomic-devel] tools and systemtap containers are available in Fedora

wcohen forwarded: > [...] >> [root@dhcp23-91 ~]# atomic run --spc >> candidate-registry.fedoraproject.org/f26/systemtap >> >> docker run --cap-add SYS_MODULE -v /sys/kernel/debug:/sys/kernel/debug >> -v /usr/src/kernels:/usr/src

  1   2   >