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: 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

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 - > [...] > > 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

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

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 >

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

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

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

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

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: 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

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

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

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

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

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?

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)

> 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

Re: Uninitialized variables and F37

siddhesh wrote: > [...] The ideal would be a rawhide-debug (or f37-build-debug, > etc) target that disables trivial-auto-var-init and maybe also some > other flags to improve debuggability, but that could be a separate > proposal. We don't build "debug" variants of the distro RPMs for a

Re: F37 Change: Signed RPM Contents (System-Wide Change proposal)

> [...] > == How To Test == > You can verify that a signature has been put in place by looking at > the extended attribute by running: `getfattr -d -m security.ima > /usr/bin/bash` (change `/usr/bin/bash` with the file to check). Can one easily query the RPM archive for the signature blob for

Re: Devtoolset for epel7 for build in Copr

Miroslav Suchý writes: > [...] Springdale provides > devtoolset-3-elfutils there, and it in some strange way badly > correlates with the initial Copr build environment (even before > the rpmbuild process starts). Some python2 module cannot find > libelf.so.1 ... I believe

Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)

Hi - > There really ought to be tested migration scripts or at least instructions > supplied. [...] > Could the Change proponents commit to producing transition instructions > for servers & clients? Recalling that such commitments were made as a part of the FESCO approval of this change (and

Re: New top-level dir: /state [

David Cantrell writes: > Reading comments and talking to people, the long standing understanding of > /var is still "that's stuff you can rm -rf and the system will still work > fine". Technically you could remove the RPM database and the system still > function [...] Considering that many

Re: use of kernel/yama/ptrace_scope in rpm scriptlets

Fabio Valentini writes: >> if [ -e "..kernel/yama/ptrace_scope" ]; then >>echo "0" > ..kernel/yama/ptrace_scope >> fi >> or, as it seems to be an irrelevant message, use > /dev/null ? See elfutils-default-yama-scope, though it uses a sysctl file rather than an echo. - FChE

Re: Shouldn't Fedora 36/rawhide kernel be 5.17 not 5.16 rc3 git?

Reon Beon via devel writes: > I see mine crashing reasonably often in Problem Reporting. Any > packages I should install? > > "The backtrace does not contain enough meaningful function frames to > be reported. It is annoying but it does not necessarily indicate a > problem with your computer.

Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

> === Relationship with IMA === > > [https://sourceforge.net/p/linux-ima/wiki/Home/ IMA] is another > technology meant to provide detection of file alterations. IMA and > fsverity operate very differently, and are somewhat complementary. > [...] Do these two systems use the same per-file

Re: sysusers scriptlets: what to do if upstream includes the config files?

Adam Williamson writes: > [...] > > https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation > > say: > > "Create a .sysusers file with the user definition and add > where usr/lib/sysusers.d/geekotest.conf is the path to one of the > sysusers config file

Re: deltarpm usefulness?

kevin wrote: > I think it's because you only see deltas from N to N+1 now and before > you saw deltas from N to N+X before. So, I think if we made it somehow > create older deltas, you would again see better savings. The issue > doesn't just cause there to be fewer deltas, but it also causes

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

bluca wrote: > This [tags for statically linked parts] would be indeed useful [...] For the original task of assisting with crash analysis, how would it be useful? The idea is that the overall binary's tags would let someone fetch the corresponding distro / debuginfo and go from there. That

Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)

Stephen John Smoogen writes: > Mainly because it is the authentication service equivalent of > telnet**. Very simple to set up, very simple to use, and very easy to > steal all the information about logins, users, and setups. [...] ... well, compared to what? LDAP commonly distributes

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

Miroslav Suchý writes: > You do not need a crash for that > /usr/libexec/drkonqi --dialog --keeprunning --pid $PID > will try to debug running application. I tried that with PID of > running vim. Nice, thanks. In the "Developer Information" tab, one can watch gdb "Downloading separate debug

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

Hi - > > If I read drkonqi sources correctly in that gdb is being used as the > > backtracing backend. That suggests that its automatic debuginfod-based > > downloading should be working on F35. Do you have a recipe for > > triggering this crash and the dr. konqi processing? > No good way [to

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

sgrubb wrote: > This brings up an interesting tangent (sorry), which I've asked on the KDE > list with no answer. When kontact segfaults, and it does a lot, it starts Dr. > Konqi and asks if you want to file a report. But because debuginfo rpms are > not installed it fails and says not enough

Re: F36 Change: Drop NIS(+) support from PAM (System-Wide Change proposal)

Hi - > == Upgrade/compatibility impact == > Users that were relying on support for NIS(+) will need to move to > secure alternatives like LDAP and/or FreeIPA. > [...] > == User Experience == > For some users this change may be a bit disruptive and it may require > some learning curve for

Re: protobuf 3.18.1 update coming to rawhide

Adrian Reber writes: > The protobuf maintainers prepared an update to protobuf 3.18.1 in > rawhide. protobuf comes, as always, with a new SO name and requires > a rebuild of all dependencies. [...] Is it futile to point them to https://akkadia.org/drepper/dsohowto.pdf in hope of avoiding this

Re: [RFC] Remove supoort for NIS(+) from PAM

Stephen John Smoogen writes: >> > The places I have seen it still being used are in Universities run by >> > people who learned sysadmin in the 1990's and early 2000's. It is a >> > light weight system which is simple to set up [...] >> >> For those people who like simple to set up and working

Re: [RFC] Remove supoort for NIS(+) from PAM

Stephen John Smoogen writes: > The places I have seen it still being used are in Universities run by > people who learned sysadmin in the 1990's and early 2000's. It is a > light weight system which is simple to set up [...] For those people who like simple to set up and working systems but are

Re: Eclipse IDE packages and friends orphaned

> [...] Eclipse tries to keep up to date with libraries shipped. Quite > often the effort of moving to new versions of a library (e.g. lucene) > requires changes in Eclipse itself Is this level of backward non-compatibility typical in Java? > and Fedora being ahead/behind with versions puts

Re: Any recent changes to the arm builders?

Kevin Fenzi writes: > It makes me wonder if we should consider letting 32bit arm go... > (insert pitchforks and torches). ... or go back to an F32 kernel? - FChE ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Eclipse IDE packages and friends orphaned

Aleksandar Kurtakov writes: > List of packages orphaned (all were maintained for the sake of Eclipse > stack): > * eclipse > [...] Could upstream eclipse make an effort to reduce its dependency footprint? - FChE ___ devel mailing list --

Re: Is the chromium debuginfo package exists?

Samuel Sieb writes: > On 2021-07-25 2:38 p.m., Mikhail Gavrilov wrote: >> Is the chromium debuginfo package exists? >> Quick searching in repos didn't find any debuginfo packages for chromium. > > There haven't been any debuginfo packages for chromium for at least a > very long time. I assume

Re: Guile & Fesco requiring package maintenance work

Kevin Fenzi writes: > https://fedoraproject.org/wiki/FESCo_meeting_process > > "Make sure to check with and invite stakeholders who may not be CC'd in > the issue. Consider deferring issue if stakeholders have not had > adequate notice and are not available for discussion." > > Perhaps it should

Re: Guile & Fesco requiring package maintenance work

Ben Cotton writes: > [...] I agree that enabling it for the fesco project would be > good. It's probably insufficient, though. When the meeting chair sends > the agenda, adding the owners on cc or bcc so that they get reminded > of time/location/etc is important. Since this gets overlooked

Re: RFC: Banning bots from submitting automated koji builds

Miro Hrončok writes: >> - releng and SIGs submitting scripted mass rebuilds (no actual package >> changes, triggered by a person) >> - bots submitting rawhide builds for ELN (no package change, just >> built for different buildroot) > Other random ideas of what should be allowed: > - a human

Re: IRC Announcement

Adam Williamson writes: > [...] > But some other channels that are not Fedora channels, but which a lot > of Fedora people are interested in, decided to move, or at least to > tell people that they also had a channel on the new network. Then > Freenode peremptorily took over those channels for

Re: IRC Announcement

adamwill wrote: > Freenode has also shut down every channel that posted a libera.chat > link in its topic. That's not very 'trustworthy'. This happened to > multiple Fedora-related projects/channels, including #cockpit , for > instance. Those organizations have announced their departure.

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

Hi - >> > [...] Most of these libraries are nothing I care about. [...] but >> > could it be possible to not download anything at this point and only >> > download debuginfos when they are really used [...] >> >> This sounds like a worthwhile suggestion for upstream gdb. We will >> follow up

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

Hi - asmadeus wrote: > - My usecase admitedly wasn't a very nice one (graphical application, > info dll says I have 265 linked libraries...), but it felt very slow. Yes, a first-time download series for such a program is going to take time. (Afterwards, it's cached.) > Looking at iftop the

Re: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

Daniel P. Berrangé writes: > The container runtime in the host OS will have configured most mount > points before the container starts. It would be relatively uncommon > for processes inside the container image to need to mount additional > volumes later. That's fair, but util-linux contains

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

f...@redhat.com (Frank Ch. Eigler) writes: > The purpose of this Change is to configure this environment variable by > default, pointing to the forthcoming production version of the server > at https://debuginfod.fedoraproject.org/. With elfutils-0.184-4.fc35, this is now active fo

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

"Sampson Fung" writes: > The first run, giving my "Try"s, takes much longer than the second run, which > gives no "Trys". > Just from impression: > 1st run: From run to download finish, I will say it takes about 5+ minutes. > 2nd run: ~1 minute > For each "Try" given, the delay is not obvious

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

Zbigniew Jędrzejewski-Szmek writes: > OTOH, the debuginfo files distributed through the debuginfod server > are not signed and there is no direct way to verify that they match > the (signed) contents of the debuginfo package. A direct way would be for someone to koji-download the given rpm,

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

Björn Persson writes: >> https://sourceware.org/bugzilla/show_bug.cgi?id=27758 > > The design you propose there won't improve anything for anyone. If the > hash is computed on the debuginfo server, then an attacker who can make > the server serve malicious debuginfo can also make it serve

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

Björn Persson writes: > I was wondering what the user experience would be like in such a > situation. Could you estimate how long you had to wait in total? Was > there a long delay before each "Timer expired" message, or only one > delay? Each outright-hung request could entail a

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

"FUNG Chi Chuen Sampson" writes: > Downloading separate debug info for /lib64/liblzma.so.5... > Download failed: Timer expired. Continuing without debug info for > /lib64/libbrotlicommon.so.1. > Missing separate debuginfo for /lib64/libbrotlicommon.so.1 > [...] By the way, if you were using

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

sampsonfung wrote: > While trying to collect a backtrace for org.gnome.Tetravex, I got this in gdb: > [...] > Download failed: Timer expired. Continuing without debug info for > /lib64/libzstd.so.1. > Missing separate debuginfo for /lib64/libzstd.so.1 > Try: dnf --enablerepo='*debug*' install

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

Hi - Björn Persson writes: > · How is it verified that files received from debuginfo servers have not > been tampered with? Following up further to this, we're planning to add optional client-side hash-verification of cached content, to provide some protection against tampering:

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

Bjorn wrote: >> https://fedoraproject.org/wiki/Changes/DebuginfodByDefault > > The change page lacks a discussion of security implications. An informed > decision requires answers to questions such as: [...] Thank you for your questions. Added a section and placed initial answers there:

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

dmalcolm wrote: > [...] > Something that occurred to me about this change is that as well as > sources and DWARF data, some of our debuginfo files contain python > scripts. Because these files are stand-alone .py files rather than elf/dwarf files, debuginfod has no way of serving those. If

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

mcatanzaro wrote: > I started testing the staging server yesterday. It seems a little slow > -- I worry for anyone debugging anything that links to WebKit, which > on the desktop is a lot -- but otherwise it works *very* well. I'm > impressed. Very nice. It'd be good to get a sense of what you

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

ngompa13 wrote: > Woohoo! I'm excited for this! Thanks! > I got a chance to use debuginfod to do some debugging of DNF on > openSUSE last Saturday and the experience was fantastic. > > I'm looking forward to this being wired up into GDB, ABRT, and > everything else Hey, it already is there in

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?

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

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

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

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

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

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

nicolas.mailhot wrote: > [...] > extracting debug info from > /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump > *** ERROR: No build ID note found in >

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

Hi, Dan - On Thu, Oct 05, 2017 at 01:49:48PM -0400, Daniel Walsh wrote: > [...] > But really for something like this, it would be better to just run > it --privileged. There is [no] security confinement present in what > you are doing. Yup. I thought "atomic run --spc" would imply "docker run

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

Hi, Dan - > Could you show the docker line that atomic run is executing? % atomic run --spc candidate-registry.fedoraproject.org/f26/systemtap /usr/share/systemtap/examples/io/iotop.stp docker run --cap-add SYS_MODULE -v /sys/kernel/debug:/sys/kernel/debug -v

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

Hi, Dan - > [...] > Rather then putting the system into permissive mode, you should run > a privileged container "atomic run --spc " fails similarly on f26, despite its underlying "docker run --cap-add SYS_MODULE ..." parts. > or at least disable SELinux protections. > > docker run -ti

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

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: 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:

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: 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

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 to

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 restriction

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 meaningful

Re: [Guidelines change] Changes to the packaging guidelines

Jason L Tibbitts III ti...@math.uh.edu 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

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]

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

Re: Automatically generated configuration files

Paul Wouters p...@nohats.ca 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 ?

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. For

Re: F21 Self Contained Change: Remote Journal Logging

Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= zbys...@in.waw.pl 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

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 delay

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 material. [...]

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

Chris Murphy li...@colorremedies.com 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

Re: Is rpmbuild reentrant?

Neil Horman nhor...@redhat.com 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

Re: Reminder on how to EOL a package

Dennis Gilmore den...@ausil.us 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

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

Richard W.M. Jones rjo...@redhat.com 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,

Re: F20 System Wide Change: No Default Sendmail

Lennart Poettering mzerq...@0pointer.de 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

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/extras

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 on

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

Re: F20 System Wide Change: No Default Syslog

Lennart Poettering mzerq...@0pointer.de 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

Re: F20 System Wide Change: ARM as primary Architecture

Adam Williamson awill...@redhat.com 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

Re: yum groupinstall development-tools FAILS

Philip Rhoades p...@pricom.com.au 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

Re: BuildRequires for texlive stuff for F18 and beyond

Jindrich Novy jn...@redhat.com 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

  1   2   >