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

[Frank Ch. Eigler]

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 back and most recently with the
> lockdown of the RHEL sources.
>
> What Red Hat has done may be technically legal and perhaps good for
> its business.  However, to me it's ethically unconscionable.   [...]

Could you elaborate how you see RH's new policy w.r.t. RHEL sources
being different from Cygnus's policy w.r.t. GnuPro sources?


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Frank Ch. Eigler]

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/fesco/#_ticket_policy...
> I don't see any violations, either in the letter or the spirit of what is
> written.

OTOH:

"The motivation for the Changes process is to raise the visibility of
planned changes and make coordination and planning effort easier. It is
nearly impossible to follow all changes happening in a big project such
as Fedora. By providing a mechanism for sharing changes, it is easier
for contributors to know what is coming and to ensure that we can
address impacts of changes well before the release date. Change
proposals should be shared as early as possible, before the change is
implemented and even in the very early state of the idea, to gather
community feedback and review."


One could argue that taking a change that was widely discussed and
clearly rejected, then initiating a sudden revote without at least as
much publicity, undercuts the "easier for contributors to know what is
coming" or "gather community feedback and review" point of the whole
thing.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Frank Ch. Eigler]

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 pointers need to be enabled across the whole system for this to
> work properly[1].  [...]

If that were true, then the fesco-mandated per-package opt-out option
would defeat this purpose, would it not?


> [...]
> [1] Perf claims to be able to use DWARF info for stack traces, but in
> our experience it does not work at all.

Please share more information about this.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Frank Ch. Eigler]

> 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 predictions
like "I'm confident that over the course of the next year, we'll recover
performance that was lost by FORTIFY_SOURCE=3 and frame pointers" and
"The optimizations enabled by profiling can be much larger than 3-10%.",
and that's just in the last few days.

There needs to be substance behind such predictions if they are going
to be used as justification for slowing things down in the mean time.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Frank Ch. Eigler]

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 sufficient to fix one or two
> performance bugs to call this change a success, or do we need more?
> Specifically how many? [...]

If I understood it correctly, the claim was that enabling this
distro-user-penalizing option would make it back in terms of performance
optimizations.  That it was an investement that would have a positive
return.

Let's be firm in testing this empirically rather than aspirationally.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Frank Ch. Eigler]

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 due to this profiling change do not in
fact appear by F39 or F40, the Change should be automatically reverted.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Frank Ch. Eigler]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Frank Ch. Eigler]

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 state might be tolerable)
> * Build in a "side tag" to prevent dependencies from failing and
> rollout once stable
> * Prepare Pull requests in Rawhide
> * Merge and build into a "side tag"
> * Once stable merge into Rawhide

Does this rebase include automated migration of existing databases?  If
not, are users expected to do it manually, based on upstream postgresql
docs?

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

IMA testing, Re: Fedora Linux 37 Beta Released

[Frank Ch. Eigler]

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 tried in a f37-beta install.
The appropriate "publiccert.der" file does not seem to be available
either.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

[Frank Ch. Eigler]

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 know if they wouldn't if profiling tools *worked*.

You said the problem isn't sysprof.  Userspace profiling tools can fully
unwind with dwarf / .eh-frame if they make the effort.  Several do.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 be capable of doing full dwarf unwinding.  The fedora copy of
sysprof is not linked against libunwind, or more modern libraries like
elfutils, but only against glibc's little emergency backtrace()
function.  If sysprof learned to speak elfutils (like the eu-stack
program demonstrates for unwinding), it could also benefit from
debuginfod dwarf auto-downloading as needed.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

>> 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...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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?

Yes.

# stap -e 'probe timer.profile { if(user_mode()) {
 print_ubacktrace() println() 
   } }' \
   -d /lib64/libc.so.6  -d /path/to/other/library --ldd 

see also, e.g.:
https://sourceware.org/systemtap/man/stap.1.html
https://sourceware.org/systemtap/tapsets/API-print-backtrace-fileline.html
https://sourceware.org/systemtap/tapsets/API-print-ubacktrace-brief.html 

> Is this trick something that perf could use as well?

Yes, but this approach is unlikely to be adopted there.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

> [...]
> 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 DWARF-based unwinding
for the kernel and user-designated userspace executables and
shared-libraries on demand, and it's not particularly slow at it.)

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

> 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 magnitude can veto such changes, especially when
they hit everyone, not just those who are highly dependent on the
profiling tools the proposal is concerned about.


> === Alternatives to frame pointers ===
>
> There are a few alternative ways to unwind stacks instead of using the
> frame pointer:

> * [https://dwarfstd.org DWARF] data - The compiler can emit extra
> [...] The problem is that we need to unwind the stack in kernel space

(Are you referring to a novel kernel-resident tool?)


> To summarize, if we want complete stacks with reasonably low overhead
> (which we do, there's no other way to get accurate profiling data from
> running services), frame pointers are currently the best option.

The proposal doesn't characterize the "reasonably low overhead" that
this operation targets.  That makes it hard to judge the tradeoffs.


> [...]
> Fedora users will be more likely to have a streamlined experience when
> trying to debug/profile system executables/libraries. Tools such as
> perf will work out of the box instead of requiring to users to provide
> extra options (e.g. --call-graph=dwarf/LBR) [...]

If typing that option were a hardship, it could be made default on
Fedora.  With broad debuginfod auto-downloading capability, maybe it's
worth considering.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Uninitialized variables and F37

[Frank Ch. Eigler]

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 variety of
reasons.  Other than the obvious (extra QA, no user base, etc.), it
confuses means and ends.  People want to run the real binaries and debug
them if necessary.  Debuggability is not the 'ends', and having
'debug' binaries is not a means toward debugging the real ones.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

> [...]
> == 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 any
given file it contains?


> The signatures can be tested “in vitro” by running `evmctl ima_verify
> --key publiccert.der -v myfile.txt`.
> [...]
> The full system could be tested by enrolling the Fedora IMA key [...]

How will this key be distributed on the distro filesystem or on the web?
Will it be signed by an already trusted CA?


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Devtoolset for epel7 for build in Copr

[Frank Ch. Eigler]

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 what's going on is that the old scl build of elfutils also
happens to include rpmbuild-generated libelf.so() virtual provides.
That tricks yum into sometimes installing that scl elfutils instead of
baseos elfutils to satisfy other packages' dependency on libelf.so.
And it won't satisfy the dependency without a custom LD_LIBRARY_PATH
(or scl enable).

Modern scl builds of elfutils go to some effort to suppress that virtual
rpm-provide.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 its sibling - the dropping of YP servers),
is this done yet?

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: New top-level dir: /state [

[Frank Ch. Eigler]

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 other valuable mutable state are put under /var
are put there, databases, container images, etc. etc. etc, this
understanding cannot be correct.  We could just leave /var alone.

# sudo du -s /var/lib/*

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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. ABRT will not allow you to create a report
> in a bug tracking system but you can contact kernel maintainers via
> e-mail."

These days, many debugging tools can automatically fetch debuginfo from
fedora servers (https://debuginfod.fedoraproject.org/).  Do you know
which abrt processing tool was complaining to you - like based on which
dead program's backtrace?

If that can't work for this tool just now, you can probably do this:
# debuginfo-install kernel

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

> === 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 signature metadata in the RPMs?

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 within the upstream source, but it doesn't seem to
> work. [...]

One problem with these sysusers rpm macros is that they expand to the
scriptlets very early: before even the main source tarball is extracted.
This is why the fedora packaging guideline more or less forces them to
be first-class spec sources.

In the case of systemtap, we worked around this by moving the sysusers
config files right into the spec file - out of the source tarball - and
feed them to %pre and %install scripts by hand.

https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec#_91
https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec#_688
https://src.fedoraproject.org/rpms/systemtap/blob/rawhide/f/systemtap.spec#_818

IMO this is ugly and unfortunate.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: deltarpm usefulness?

[Frank Ch. Eigler]

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 those
> few be be against very recent changes, so less effective.

That should be fun to quantify.  Heck, in principle it could be possible
for a client to use a sequence of deltas to go from some random older
version to the current one (sort of like shellsort).

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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
lookup operation does not need version tags for all the individual bits
of source and object code that went into that binary.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 crypttext
passwords and databases with about the same amount of discernment and
theft-enablement as ypserv.  Plaintext as in telnet makes an appearance
nowhere but with yppasswd, AFAIK, which is nonessential.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 info for ..." lines, so the debuginfod
machinery is working fine.

(... except in the case of binaries that have been replaced since they
started running, since drknoqi runs the child gdb, targeting
/usr/bin/path name rather than /proc/$PID/exe.)

(... and except that drkonqi advises "The generated crash information is
not useful", though the backtrace info looks nice and complete.)

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 reproduce]. After composing the above email, I
> noticed it was lingering in the outbox. After some poking around, I
> found that one of the mail agents was no longer on dbus. I can only
> speculate it segfaulted.

Bummer.

> And because it says no debug information, I don't have any clue
> where in kontact problems are happening. 

With debuginfod env vars set up, it shouldn't say that.  It (gdb or
similar) should just go ahead and download it.  If that's not working
in this context, I'd love to look closer why.

> [...]
> But if there is a new feature in F35 that make crashes meaningful again

https://fedoraproject.org/wiki/Changes/DebuginfodByDefault should help

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 info to file a report. [...]

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?

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 switching to alternative solutions.
> [...]
> == Documentation ==
> The documentation about sharing system users and files over NIS should
> be dropped, if there even is any.

There really ought to be tested migration scripts or at least instructions
supplied.  On a test server machine, I'm playing along with docs snippets

https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/servers/Directory_Servers/

and finding contradictions ("avoid editing LDIF files within
/etc/openldap/slapd.d" then edit "/etc/openldap/slapd.d/cn=config.ldif")
and migrationtools scripts are failing this way and that.

Could the Change proponents commit to producing transition instructions
for servers & clients?

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: protobuf 3.18.1 update coming to rawhide

[Frank Ch. Eigler]

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 in the future?

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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
>> willing to consider upgrading if it's also simple and will keep working,
>> is there a NIS->$whatever migration document in fedora someplace?
>
> I don't think anyone has come up with an agreed upon $whatever that a
> majority of people like. There is LDAP but that isn't light. There are
> kerberos but that isn't easy. 

"light" in terms of CPU/network, who cares.  "light" in terms of
simplicity and maintenance, you have my attention.  If there is no such
gadget available, then please let's keep NIS around.


> And honestly the cool kids only want web logins these days as servers
> are a pain and why not just login into Google/Facebook/Microsoft and
> let them deal with all that setup.

(OK but seriously that's not a fedora matter.  Well, or rather, I'd love
to have a passwd/nss backed openid gadget.  Is that ipsilon?)

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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
willing to consider upgrading if it's also simple and will keep working,
is there a NIS->$whatever migration document in fedora someplace?

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Eclipse IDE packages and friends orphaned

[Frank Ch. Eigler]

> [...]  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 too much burden on
> the maintainer. This is the number two item when classified by time
> spent.

Fedora could ship some frozen/LTS versions of libraries, if these exist
and do not constitute a security problem.  If that's not an option
either, to this outsider it looks like building on quicksand, paddling
as fast as possible to stay above the mud.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Any recent changes to the arm builders?

[Frank Ch. Eigler]

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 devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Eclipse IDE packages and friends orphaned

[Frank Ch. Eigler]

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Is the chromium debuginfo package exists?

[Frank Ch. Eigler]

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 it's disabled for some reason.

chromium.spec sez:

# Debuginfo packages aren't very useful here. If you need to debug
# you should do a proper debug build (not implemented in this spec yet)
%global debug_package %{nil}

People calling for it suggests the assertion of being "not very useful"
may be mistaken.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Guile & Fesco requiring package maintenance work

[Frank Ch. Eigler]

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 be more explicit in how to "check with and invite"?

Not sure about that cc:-on-the-issue condition.  There appears to be no
systematic notification *in the issue* that the topic is on the next
agenda, so people on the cc: list are not automatically invited.
There's also no notification in the wiki Change page, so those watching
that don't know either.  Can this get fixed?  Those two bits of extra
process might be enough to ensure that change proponents feel invited.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Guile & Fesco requiring package maintenance work

[Frank Ch. Eigler]

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 with some regularity, a mechanical way of
getting notified / invited to relevant fesco meetings should be a
priority.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: RFC: Banning bots from submitting automated koji builds

[Frank Ch. Eigler]

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 approves a pull request, bot merges it and builds
>  - a bot rebuilds packages automatically (bump-only or no changes),
> when dependencies change

A simpler way to phrase that would be:

"No autonomous bots are to push builds into rawhide or release branches."

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: IRC Announcement

[Frank Ch. Eigler]

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 posting links to the
> new channel.

In the cases where the projects announced their outright move to a new
server, it stands to reason that keeping an "official" (#name) channel
is no longer appropriate at the old network.  The response of cleaning
up after a no-longer-official channel cannot logically be used to
justify moving the channel in the first place - this is the circular
reasoning I was referring to.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: IRC Announcement

[Frank Ch. Eigler]

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.  Surely freenode's
RESPONSE to that departure cannot be used as the REASON for the
departure.  That'd be circular reasoning and a self-fulfilling prophecy.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 with them.

https://sourceware.org/bugzilla/show_bug.cgi?id=17547


>> OK, in my experiments, ^C did work, so something must have broken here.
>> We will follow up with gdb folks.
>
> [...]
> (For others: ^c cancels the download of a single object file, so might
> need quite a few of these to eventually get to a gdb prompt if there are
> many objects to download, but it works)

https://sourceware.org/bugzilla/show_bug.cgi?id=27911


> [...]  Interesting, I wasn't aware of such a debuginfod proxifying
> mode.

Yes, we refer to it as "federation", and designed into debuginfod from
the beginning, so that one can establish a tree of servers, e.g. along
personal/group/corporate/public sorts of lines.


> Are there noticeable advantages over a simple caching http proxy
> (e.g. squid) besides serving off in-house binaries debuginfo along the
> way?  [...]

It should be about the same, except cache management policy is
different, and that debuginfod will pass requests to its upstream peers
*concurrently*, so this can create more redundancy and possibly
performance.  By design, squid proxies or CDNs should interoperate just
fine with debuginfod and within federation trees.


> [...]
>> That sounds like something that could fall out from this effort [1], when/if
>> comes to fruition.  We in debuginfod land could naturally follow up with
>> interfacing & checking glue code.
>> 
>> [1] https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
>
> Hm, I guess debuginfod could distribute the signature files together
> with the dwarf files straight from the rpm, but I'm a bit pessimistic
> whether everyone will have IMA enabled even at relatively long term.
> The change proposal does state that they won't actually enforce
> anything:

Right, I'm referring only to that if the per-file signatures were built
& packaged, we could trick the debuginfod client/server to use that for
manual signature checking, vs. relying on selinux/kernel enforcement.

> I guess I'd be fine with that if the debuginfod client implements the
> signature verification in userspace regardless of the policy if
> configured for it (I almost wrote if the server sends it, but that'd let
> malicious server just pretend there is no signature available... heh),

(Good point!)


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 server was reliably sending me things at 1mbps
> which isn't great but with the amount of data involved being slow can't
> be helped, I guess.

Right.  The fedora debuginfod server seems well situated on the net, so
can generally send you compressed DWARF files fast.  (I'm getting 5ish
megabytes/s across https.)


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


> [...]  - None of ^C, ^\, ^Z work, when I grew tired of waiting I had
> to switch to another terminal and kill the gdb process. [...]

OK, in my experiments, ^C did work, so something must have broken here.
We will follow up with gdb folks.


> - unsetting DEBUGINFOD_URLS completely disables the debuginfod client,
> it would have been nice to use the data available in the client cache
> anyway.  Ultimately I set it to localhost so debuginfod would give up
> immediately on new requests but still use previously downloaded data.
>
> Perhaps there could be an "offline mode" of sorts?

I'll document this trick on the wiki.  

By the way, consider operating your own debuginfod (rawhide or 0.185)
server, federating to upstream.  The gdb-gui-download-series process you
experienced could be maybe twice as fast, due to http connection
keepalive improvements.  Maybe even faster, once gdb itself takes direct
advantage (patches there are pending).  Plus you get a shared cache for
your network.


> [... re. security ...] (distributing just checksums of all debug files
> in the main package, so when debuginfod downloads something it can
> compare with the checksum that was installed and verified locally by
> signed rpm?

That sounds like something that could fall out from this effort [1], when/if
comes to fruition.  We in debuginfod land could naturally follow up with
interfacing & checking glue code.

[1] https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents


> All in all I think it's a very valuable tool, but it would be really
> great if we could minimize the amount of data actually downloaded, and
> establish some chain of trust.

I'm hoping we can make some improvements between now and F35 release,
though practically all of these rely on changes to other projects.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 many other tools that may be useful
at runtine within a containerized tool (logger, flock, lsmem, rename,
taskset, whereis, others?).  Some those be moved somewhere else?

/usr/bin/* files from f33's util-linux:

cal chmem choom chrt col colcrt colrm column dmesg eject fallocate
fincore findmnt flock getopt hardlink hexdump i386 ionice ipcmk ipcrm
ipcs irqtop isosize kill last lastb linux32 linux64 logger login look
lsblk lscpu lsipc lsirq lslocks lslogins lsmem lsns mcookie mesg more
mount mountpoint namei nsenter prlimit raw rename renice rev script
scriptlive scriptreplay setarch setpriv setsid setterm su taskset ul
umount uname26 unshare utmpdump uuidgen uuidparse wall wdctl whereis
write x86_64

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 for rawhide.  If you're
interested in testing, please "# yum update", and try debugging things.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

"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 to me.

I'm pretty sure Sampson was affected by a proxy.stg.fedoraproject.org
misconfiguration problem that was fixed about an hour ago, so those
timeouts should not be happening any more.  That means we'd be down to
normal service latencies ameliorated by caching effects.

A cute demonstration of the cost/benefit of this capability now in the
distro, I recently ran

% gdb /usr/bin/gnome-control-center

On a normal machine, you'll get no debuginfo and a suggestion to install
a wall-of-text list of RPMs as root.

On a debuginfod configured machine, you'll get gdb downloading ~400MB of
debuginfo (HTTP compressed -- decompresses to ~6GB) as rapidly as your
network connection allows.  This could take some minutes, for the first
time.  After that time, you get instant visibility into the entire
enormous gnome software stack, including LLVM, mesa, x11, samba, gst,
opengl, glib, etc. etc. etc.  right down to the glibc assembly wrappers
for syscalls.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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, and
hand-extract/compare the files.  (It's obviously not economical.)

> Thus, the debuginfod server becomes a juicy target.

Yes.  The Changes FAQ section discusses this topic.

Unfortunately, in the absence of per-file signatures generated by the
build system, and securely distributed out-of-band, I can't think of any
way to provide client-side verifiability of a debuginfod type service.
That's independent of any particular level of server code robustness.

Interestingly, if debuginfod were considered *trusted*, then it could be
used as the *basis* for such a capability, because the client-side hash
verification feature being prototyped.  It would serve trusted hashes to
RPM-based artifacts on demand.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 hashes that
> match the malicious files. 

Yes, this does not provide protection against a penetrated server.  It
does not claim to.

> And as you noted yourself, an attacker who can manipulate cached files
> client-side has already taken over the user account anyway.

Yes and no, and so I must disagree with your "won't improve ... for
anyone".  The proposed client-side verification is roughly analogous to
running "rpm -V" on a machine.  Yes, if an attacker has control at that
moment, it's not reliable.  Nevertheless, to detect residue of a
-previous attack- or accidental data corruption, it can be worthwhile.

> [...]  I see that debuginfod.fedoraproject.org is currently another
> name for koji.fedoraproject.org. 

They are separate VMs, if that's what you mean.  (You may be confused by
use of a number of shared HTTP front-end proxies.)

> Given that it serves debuginfo only for Fedora packages, and does not
> forward requests to any other debuginfo servers, using this server
> seems equivalent security-wise to downloading unsigned packages from
> Koji.

Not exactly.  All the data is -from- signed packages.

> To make the debuginfo protocol as secure as signed debuginfo packages,
> the client should verify the files against a hash computed and signed
> on the signing server.

If the threat model includes a -local active attacker-, then this would
not help either.  An attacker could interfere with the local keystore
and/or trust chains and/or signature verification software.

> For those who are concerned about privacy, the proposal would make
> that problem worse as it would cause the "phoning home" to happen
> every time they debug something.

That's if they wish to rely on live verification.

Note that the privacy being leaked consists of the hex buildid of the
program being debugged, and an elfutils#/fedora#/arch, and of course IP
address.  It's not nothing, but it's nothing more.  It's roughly
equivalent to the dnf-automatic.timer call-home in this respect.

> By the way, the change page still doesn't say enough about how network
> problems will affect the user experience. [...]

I'm not sure why you say "still" when this question was not posed here
before.  I will add some text on this.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 $DEBUGINFOD_TIMEOUT (default
90s) wait.  The common code does not "hold a grudge" against a server
that formerly timed out.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

"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 the staging (.stg.) debuginfod server,
please switch to the main one, which is in full service.

DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/

We're currently tracking down some infrastructure/proxy problem that
intermittently affects only the .stg. ones.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 
> /usr/lib/debug/.build-id/33/70d80a1bf749b3c2baaad0188c864ee9e4bbc4.debug
> [...]

We have had reports that from some corners of the internet (e.g. behind
the "great firewall"), that maintaining a waiting HTTPS connection for
10s of seconds was fragile.  Extending the $DEBUGINFOD_TIMEOUT on the
other hand was sometimes reported to help.

https://sourceware.org/bugzilla/show_bug.cgi?id=27531

Looking over the system logs for that particular request (3370d80a...),
I'm seeing debuginfod.fedoraproject.org answer that particular buildid
in about tens of milliseconds (!) a bunch of times, and one failure to
transmit (usually a broken HTTP connection).  If you could send me
(directly) the IP address from where you requested it, and the
$DEBUGINFOD_URLS you were using, I could look further in the logs.  But
so far I see no sign of something triggering timeouts on this side.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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:

https://sourceware.org/bugzilla/show_bug.cgi?id=27758

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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:

https://fedoraproject.org/wiki/Changes/DebuginfodByDefault#Security_FAQ

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 they were embedded
inside the DWARF file as a special section, then it could travel
implicitly.


> [...]
> Having the sources and DWARF on-demand via debuginfod sounds great, and
> hopefully means never having to manually install debuginfo rpms again -
> but what about those .py files?

If we were interested in serving them, we could do it by extending the
webapi protocol with a way to refer to a buildid-indexed
debuginfo-related file.  Like
 /buildid/BUILDID/debuginfo-gdb.py

> [...] I'm much more nervous about arbitrary python scripts being
> supplied over this service, as the barrier to entry for bad guys to do
> Bad Things would be so much lower as compared to malformed DWARF [...]

Perhaps ... I'm not sure bad DWARF is inherently safer than bad Python.
Nevertheless, all this is based on the proposition that the files are
coming from a generally trusted build system, serving trusted artifacts
maintained by trusted individuals.  If malevolent enough files get in
there, the service can be degraded and/or clients can be affected.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 found slow.  The .stg. server is
just finishing up ingesting all the koji rpms, so has been fully
occupied with that.  In the case where a new file is sought from inside
some large rpm, yeah there will be some inherent latency in
decompressing it (CPU bound), saving the selected file to tmp disk
(RAM/storage bound) and then sending you the file (network bound).

At the server, there are some prefetching/caching options available to
take advantage of the spacious servers kindly provided by fedora-infra.

There is also aggressive caching on the client side, with an adjustable
week-long retention for files.  See the CACHE section in [man
debuginfod_find_debuginfo].  Plus web caching proxies or federated
intermediate debuginfod servers can add site-level caching near you.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Frank Ch. Eigler]

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 most tools, try it.

% export DEBUGINFOD_URLS=https://debuginfod.stg.fedoraproject.org/

and shortly all F32+ packages/versions/architectures will be debuggable
that way.  (The staging indexer is processing the l* packages, after a
few days of churning from 0* through k*.  It has a one or two more days
to go, but may already be used.)

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


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: interest in debuginfod as fedora service

[Frank Ch. Eigler]

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?

Another possible integration path would be simply to co-site the retrace
and debuginfod services.  The former already needs to mirror (or
directly access?) various distro RPMs.  debuginfod could use the retrace
server's rpm repo as its source.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: interest in debuginfod as fedora service

[Frank Ch. Eigler]

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 understand it, the retrace server doesn't serve debuginfo - it
consumes it.  An exception appears to be the "symbol transfer" machinery
(faf/pull/387 ?), but even there it appears to memoize individual symbol
table lookup results, as opposed to transferring debuginfo dwarf files.

It would be possible to make faf a client of debuginfod, so such a
server could run in more places, not just at fedora HQ.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

interest in debuginfod as fedora service

[Frank Ch. Eigler]

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 way of getting at it.  But did you know that we
have a better way?

DEBUGINFOD has been a part of elfutils since late 2019.  It can serve
debuginfo and source code for your own or for other people's binaries
to a whole gamut of tools.  (GDB 10 will include support too!)  It
works across HTTP, no root, no manual debuginfo-install, no big
downloads, no big deal.  There are even some public servers that have
some Fedora content already, as well as from other distros.  This page
covers more about the client & server situation:

  https://sourceware.org/elfutils/Debuginfod.html

You can try it today against our test server:

  % export DEBUGINFOD_URLS=https://debuginfod.elfutils.org/
  % export DEBUGINFOD_PROGRESS=1
  % # $debugger-type-tool /path/to/program
  % eu-stack -v -p $$
  % stap -L 'process.function("*").call' -c /bin/ls


The problem is that Fedora itself doesn't run a server, and our test
server can afford to carry only a subset of debuginfo/debugsource rpms
& architectures.  So, fedora developers / users cannot get at all the
info, or from an official source.  I wonder if it's time to get one
set up.  If there is interest, I'd be happy to start discussing
logistics with fedora infrastructure folks.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Frank Ch. Eigler]

> > [...] 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, keep it on the air etc. 

Surely what we want to minimize is total cost, not just one
department's expenditure.  For that, you'd need to have the
gitlab costs to compare.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: CPE Git Forge Decision

[Frank Ch. Eigler]

> [...] 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 unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: debuginfod non-standard-uid and cache permissions

[Frank Ch. Eigler]

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/cache/debuginfod -s /sbin/nologin \
>-c "elfutils debuginfo server" debuginfod
>exit 0

These are all intended to use the preferred "dynamic allocation" model:

https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Frank Ch. Eigler]

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
> /builddir/build/BUILDROOT/golang-github-performancecopilot-speed-2.0.0-1.el7.llt.x86_64/usr/bin/mmvdump

See https://fedoraproject.org/wiki/PackagingDrafts/Go#Build_ID

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Frank Ch. Eigler]

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 --privileged"
but it doesn't seem to.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Frank Ch. Eigler]

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 
/usr/src/kernels:/usr/src/kernels -v /usr/lib/modules/:/usr/lib/modules/ -v 
/usr/lib/debug:/usr/lib/debug -t -i --name systemtap-spc 
candidate-registry.fedoraproject.org/f26/systemtap 
/usr/share/systemtap/examples/io/iotop.stp

... which fails.  But a hand-run % docker run, with "--security-opt
label:disable" added in the front works for me.


> The LABEL would be the preferred way.

Sure, just someone(tm) needs to find the Dockerfile in git.  I
couldn't find it from a dozen minutes reading
https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
and pals.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Frank Ch. Eigler]

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 --security-opt label:disable ...

Is there an atomic(1) command line equivalent for this?  Or would
one have to put the security-option bits into the Dockerfile LABEL?


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Frank Ch. Eigler]

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/kernels -v /usr/lib/modules/:/usr/lib/modules/ 
>> -v /usr/lib/debug:/usr/lib/debug -t -i --name systemtap-spc 
>> candidate-registry.fedoraproject.org/f26/systemtap 
>> 
>>  [...]
>> ERROR: Couldn't insert module 
>> '/tmp/stapNEjJDX/stap_4f013e7562b546a0316af840de9f0713_8509.ko': Operation 
>> not permitted
>> [...]

I bet
   # setenforce 0
makes it work for you.  As per audit.log:

type=AVC msg=audit(1507222590.683:7940): avc:  denied  { module_load }
for  pid=7595 comm="staprun" scontext=system_u:system_r:container_t:s0:c534,c921
tcontext=system_u:system_r:container_t:s0:c534,c921 tclass=system permissive=1


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Deprecate TCP wrappers

[Frank Ch. Eigler]

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
> filtering should be done in network level or completely in application
> scope if it makes sense. [...]

Usefulness is in the eye of the beholder.  It is certainly useful to
some people today, as a defence-in-depth measure if nothing else.


> Another factor which has driven the deprecation of this package is the
> lack of any upstream community around it. 

A simple finished piece of software does not require an upstream community.


> Although the threats on networking communications increase, the threat
> coverage of this package has remained the same the last two decades,
> suggesting that new threats are now being handled on different
> components. [...]

This does not mean that the threats handled adequately by tcp-wrappers
are moot or irrelevant.

If despite objections like this, y'all were to go ahead and ditch
tcp-wrapper linked-in support, please at least request retention of 
capability to wrap the servers with tcpd (or equivalent) ourselves.


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Diagreement with pkgconfig removal

[Frank Ch. Eigler]

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:

BuildRequires: pkgconfig
BuildRequires: foo-devel

Yes, this is not canonical pkgconfig(foo) & perfect & stuff, but it's
worked for years.  With the new changes, it breaks builds:
[...] https://kojipkgs.fedoraproject.org//work/tasks/2704/17392704/root.log

DEBUG util.py:421:  Error: package
pkgconf-pkg-config-1.2.0-1.fc26.aarch64 conflicts with pkgconfig <
1:0.29.1-2 provided by pkgconfig-1:0.29.1-1.fc25.aarch64


- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Frank Ch. Eigler]

>> > [...]  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 SIGHUP /
SIGPIPE?  Users could still deliberately interrupt it with SIGINT, but a
terminal closure could in theory let it finish unmolested.

- FChE
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: kmods and Fedora

[Frank Ch. Eigler]

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 Restricted Boot and especially our implementation of
>> it (requiring kernel modules to be signed) is a very bad thing.
>
> How do you expect to be able to ensure that the kernel only loads "known good"
> modules if you can insert random modules that might subvert SecureBoot and
> all that it allows to secure?

For systemtap on secureboot systems, we rely on Machine Owner Keys.
These keys are generated once.  The public half is put into UEFI via
mokutil and a reboot.  The private half held at another trusted
machine.  Then that machine can sign modules with the MOK key and have
normal Fedora kernels/shims accept them.

- FChE
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Guidelines change] Changes to the packaging guidelines

[Frank Ch. Eigler]

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 improve clarity!

No good deed goes unpunished! :-)

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Guidelines change] Changes to the packaging guidelines

[Frank Ch. Eigler]

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 and thus more secure.)


 Nevertheless, you raise an interesting question in general.  The way
 I understand the motivation for the restriction is to avoid any
 chance of attack or unexpected access over the network.  [...]

OK, so the question is - are we (still) trying to preclude -local-
escalation-of-privileges type problems?  If not, then many more
services can be enabled by default - as long as they bind only to
unix-domain sockets and/or localhost.  (I guess we're not supposed to
count on the default firewalls?)


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Guidelines change] Changes to the packaging guidelines

[Frank Ch. Eigler]

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 distinction to be
 made between allowing services that listen on D-BUS or a local UNIX
 socket and services that listen on the localhost TCP socket [...]

Indeed.

 I'd personally prefer to assume the best intentions of our packagers;
 specifically I'd assume that if there's a question as to the safety of
 starting something by default, either they'd bring it up voluntarily or
 someone would do so on their behalf if a problem was discovered.

This is not about trusting the code or intentions of the packagers.
This is about what threat model are we expected to protect against by
not activating e.g. all services by default.  Specifying that would
help clear up -why- the change, and that will in turn inform -how- to
change.


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Guidelines change] Changes to the packaging guidelines

[Frank Ch. Eigler]

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 services are now
permitted by default (despite the risk of e.g. privilege escalation
that we had tried to preclude before)?


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Join to Mozilla Location Service in Fedora

[Frank Ch. Eigler]

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.mozilla.com/downloads (wifi networks)

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

activating services by default, definition of network sockets

[Frank Ch. Eigler]

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 services must not be enabled by default.

I'm thinking about how this needs to apply to server processes
associated with performance co-pilot (pcp).  The various daemons can
be set to listen on any mixture IPv4 / IPv6 / AF_UNIX sockets.  We
think it would be a fine performance-data-gathering background service
to run (deeper than sar but still tiny overhead), but default-on
appears to be precluded by the policy.  Or is it?

Is the intent of this policy to prevent unintentional remote access to
the services from a network (ignoring the default firewall)?  If so,
then a server restricted to localhost and/or AF_UNIX parts should be
allowed to be enabled by default.

Can someone clarify the intent / definitions of this constraint?

[1] https://fedoraproject.org/wiki/Starting_services_by_default
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Automatically generated configuration files

[Frank Ch. Eigler]

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 ?

Probably all that listen on ssl/tls-capable sockets.  (stap-server 
pcp happen to be ones freshly in mind).  In the absence of
network-layer opportunistic encryption, it's the best we can do.


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Frank Ch. Eigler]

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
 example, it pretty much explicitly forbids the use of non-free
 components in the creation of Fedora (sorry, folks: you can't use
 Photoshop to create your package icon!). 

Aren't you over-reading the quoted sentence?  ISTM one can use any
tool one wants to to produce the artifacts, as long as those artifacts
do not mandate proprietary widgets for further use.  In other words,
draw the logo with any tool - just export it in forms that FOSS can
render/edit.


 [...]
 Functional means that the Fedora community recognizes this to be the
 ultimate truth: the purpose of an operating system is to enable its
 users to accomplish the set of tasks they need to perform.

 The Functional Foundation should be placed above the other four and
 be the goal-post that we measure decisions against: If we make this
 change, are we reducing our users' ability to work with the software
 they want/need to?. [...]

Some examples of what you're thinking about would be useful.  It's not
too hard to reduce it to absurdity with a user wanting to work with
MSIE 8 on his workstation, or run MacOSX Safari, or ios angry
birds or such; what would be your idea of an appropriate or
inappropriate Fedora response to that kind of user desire?


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 Self Contained Change: Remote Journal Logging

[Frank Ch. Eigler]

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 files being created by anything
other than systemd?  If not, are these python/curl/etc. clients
just substitutes for journald neglecting to upload its files earlier?

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: default local DNS caching name server

[Frank Ch. Eigler]

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

 It's also not *needed* in a lot of setups. [...]

The cache-hit latency to a local daemon vs. a shared network daemon
can be significantly different.


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Frank Ch. Eigler]

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

Considering the inherently political and subjective nature of this,
could those policy terms be clarified so that offensiveness is
defined simply by fesco construal?


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

[Frank Ch. Eigler]

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 mirroring. RAID 10. Or RAID 1
 + linear + XFS for deterministic workloads.

Doesn't the size argument assume that some drives are set aside for
rootfs only?  Otherwise, it's reasonable to apply the same raid5/6
trade-offs to rootfs as to the other data on a shared pool of drives.

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Is rpmbuild reentrant?

[Frank Ch. Eigler]

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 subrpms.  Is
that not sufficient?

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Reminder on how to EOL a package

[Frank Ch. Eigler]

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 Conduct: http://fedoraproject.org/code-of-conduct

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

[Frank Ch. Eigler]

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, perhaps some
reference to unique build-time source trees.  But anyway, pure
content-based build-ids are IMHO misguided (since they presume
non-conflict from external coincedences), thus my salting
proposal/patch in BZ1002341.

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 System Wide Change: No Default Sendmail

[Frank Ch. Eigler]

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 change because
 we are deeply suspicous of any change that is against our
 tradition.  [...]

It's tempting to carry this argument too far.  We can be first with
good new ideas; first with experimental stuff; first with additions.
We need not be first with bad ideas (and discussions here are a way of
figuring out good from bad, let's not beg the question).  We also need
not be first when it comes to subtraction of functionality.

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Frank Ch. Eigler]

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

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Frank Ch. Eigler]

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

Considering that kexec/kdump events get triggered asynchronously
(whenevery the kernel panics), someone cannot be assumed to be sitting
physically at the terminal, ready to press a sysrq to make that
secureboot-disabling transition.  (One wouldn't want to press
sysrq-foo too early, since AIUI it's a one-way transition.)

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Frank Ch. Eigler]

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 imitators (ssmtp, msmtp)
that could be trained to block until mail is delivered, and return
error return codes upon rejection.

 And it's just not possible to automatically configure e-mail. [...]

As for outgoing SMTP, DHCP packets can identify servers; so can DNS heuristics.

 I think the way forward is to encourage applications to _log_ rather than to
 send e-mail, via this or any other API. That can be configured for e-mail
 alerts if the admin really wants. But without configuration, nothing is
 going to happen _anyway_.

Such a transition should come along with all the tooling needed to
emulate the status quo - i.e., scraped-log-to-email scripts.


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Frank Ch. Eigler]

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 can still turn that option off.  But by default,
 everyone can still grep /var/log/messages.

 Not. Gonna. Happen.

OK, how about this other idea.  Include a default-on systemd service
that runs

   journalctl --full -f  /var/log/messages

in the background.

 The journal is not an implementation of syslog, we already have that in
 rsyslog. Also, the feature is about ending the duplicate storage of the
 log messages [...]

Considering log rotation, and an effect of the above ( vs ) being
that only the current boot interval would be logged in the text file,
there would not be much savings to worry about.  Perhaps this could
be an acceptable compromise.

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: ARM as primary Architecture

[Frank Ch. Eigler]

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
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: yum groupinstall development-tools FAILS

[Frank Ch. Eigler]

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
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BuildRequires for texlive stuff for F18 and beyond

[Frank Ch. Eigler]

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 install: texlive-scheme-full [...]

So why would we try so hard to optimize the build-time footprint,
(which really only benefits koji), if for users we suggest installing
the whole kaboodle?


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BuildRequires for texlive stuff for F18 and beyond

[Frank Ch. Eigler]

Hi -

jonathan.underwood wrote:

 [...]
 With the more fine grained texlive packaging in F18 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-collection-latexextra  (nb.
 texlive-collection-latexrecommended isn't usually sufficient)

 2) Generate a list of specific style files [...]
 and turn this into a list of specific BuildRequires: tex(foo.sty) lines.
 [...]

 What do folks think?

FWIW, we didn't enjoy finding the magic tex(XXX) buildreq's to build
systemtap docs during %build; not sure how confident we can be that
they'll stay valid.  (1) sounds good to me.


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Fedora Upgrade - using yum

[Frank Ch. Eigler]

Simo Sorce s...@redhat.com 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 during changes in the configuration or upgrades, that is
 non-negotiable to me. [...]

I agree that this capability is very important.

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Thoughts on SystemTap, Perf and LTTng ?

[Frank Ch. Eigler]

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 about the current
 and expected state of the three in Fedora and opinions about the
 relative merits. [...]

Each of them is small and interesting enough that time taken to play
with them all won't be wasted.  They are different in many ways, and
have different capabilities / restrictions, but each should roughly be
able to do what you need.

http://sourceware.org/systemtap/wiki/SystemtapDtraceComparison


For purposes of avoiding peppering code with tracing statements, I
suspect systemtap would be the easiest, in theory:

# stap -e 'probe process.statement(function@foo/bar.c:2322) {
 printf(var1=%d var2=%s\n, $var1, user_string($var2))
}' -c ./a.out ARGS


- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: LibRaw: possible license issues

[Frank Ch. Eigler]

Debarshi Ray rishi...@lostca.se 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://admin.fedoraproject.org/mailman/listinfo/devel