Recent updates on f27 are blocked because openssl-devel (1.1) conflicts
with compat-openssl10-devel (1.0). A large number of packages depends on
1.0, so the only way to upgrade is to --allowerasing, which deletes
openssl 1.1 devel packages (
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1625440" title="https://bugzilla.redhat.com/show_bug.cgi?id=1625440">https://bugzilla.redhat.com/show_bug.cgi?id=1625440</a> ). Those packages
used to coexist peacefully up until recently.

I understand that we want to move to openssl 1.1 but the current reality
is that it's pushed off the system.

The primary logged-in session is of course authorized to access the main
X11/wayland display, but it's often useful to add display authorization
to other accounts. For instance, looking at disk space with 'baobab'
works better as root because some areas of the filesystem are not
readable to normal users (*). I used to do such authorization by

xhost +si:localhost:root

but it recently stopped working:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1527754" title="https://bugzilla.redhat.com/show_bug.cgi?id=1527754">https://bugzilla.redhat.com/show_bug.cgi?id=1527754</a> . Is there another
way of authorizing display access for other accounts?

I ran into a problem with midi-disasm from soundfount-utils. I tried to
debug it but installing soundfont-utils-debuginfo only brings in the
symbol tables, not sources.

I know that we started splitting the source packages off---but
unfortunately there doesn't seem to be soundfont-utils-debugsource
anywhere. In fact, the sounfount-utils package is a little bit of a
mystery: I couldn't find it on the Fedora package list, and it doesn't
show up in Bugzilla so I can't enter a bug against it.

proposing a unified sqlite database for DNF. Recently there's been a
discussion of replacing the RPM database with a custom database layer,
where people asked why aren't we using something like sqlite---which I
think is a reasonable idea, and even more so if the FESCo idea is
approved and we have sqlite linked into DNF anyway. I just wanted to
point out the connection, and the possible synergy (BS BINGO!!! BS BINGO!!!)

This blocks upgrades for dependent packages (perl*, git*, vim*), while
polymake can't just be bypassed because it is a dependency of quite a
bit of other packages (python*, gap*, sage*, ocaml*), so it's a stalemate.

I reported that in <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1415548" title="https://bugzilla.redhat.com/show_bug.cgi?id=1415548">https://bugzilla.redhat.com/show_bug.cgi?id=1415548</a>

Now, the reason I mention it here is that I noticed a number of update
hiccups recently, resulting from strict checks by DNF.

Easy access to debug information is very well done in Fedora, and is one
of its most empowering features. It's very easy to trace problems: 'gdb
program' even prints out the 'dnf debuginfo-install' command required to
load symbol tables and source for everything on the system. Thanks to
that, we make it easy for the end users to get engaged finding problems
and fixing bugs, which is good for everyone involved.

I was always impressed with the amount and quality of audio software in
Linux. When it all works, and is driven by someone who knows what
they're doing, it's essentially a high-end DAW production environment.
If it all worked smoothly, I am sure it could be one of Linux and Fedora
showcases.

I am a musical dilettante, so my attempts have been perhaps haphazard,
but I had a mixed luck: I was able to get everything to run, but the
setup seemed very brittle.

There were 109 packages for which there was no upgrade; 62 are
*-debuginfo, 12 are from various oddball repos (adobe, simulavr, etc),
but 36 are I believe regular Fedora Core 20 packages, including fairly
important ones like 8 related to the R language.

Two of those result in packaging conflicts and fedup warns about
'upgrade at your own risk':

I was curious about the rate of bug reporting in Fedora, and did this
quick experiment. I thought it might be interesting to folks here who
either work on the infrastructure or are curious about long-term
collaboration trends in Fedora.

I checked the date of reporting of every 10,000th bug (bugzilla #1,
#10000, etc, all the way to the recent 1150000---see attached data).
Some bugs were private so I didn't have access to their info, but I got
enough data to calculate bug velocity (increase in the bug number
divided by the time interval) over time.

[I posted it once already, but it ended up buried in another discussion
thread due to a botched InReplyTo]

Is libatasmart a going concern? The functionality overlaps with
smartmontools, and the development seems to have stalled [1]. I
originally started using libatasmart few years ago because it had better
support for USB bridges, i.e. it allowed reading SMART data from USB
external enclosures, which smartctl couldn't do at the time.

Recently, however, I ran into issues in skdump reading the SSD SMART
attributes.

Since clock-applet is a default install on every Fedora, I thought this
would be widely reported---it essentially makes the system unusable
within a day or two if you run into this problem---but that doesn't
seem to be the case.

I filed this under <a href="https://bugzilla.redhat.com/show_bug.cgi?id=821079" title="https://bugzilla.redhat.com/show_bug.cgi?id=821079">https://bugzilla.redhat.com/show_bug.cgi?id=821079</a>
but this may be a SSH buffer overflow problem so I decided to post a
heads-up here.

I have Fedora desktops talking SSH to RHEL 6.2 servers. F16 worked fine,
but I started getting mysterious connection failures with F17:

I booted the F17 beta ISO (x86_64, if it matters) on two laptops and
tried the provided memtest. In both cases it reported insane amounts of
errors in test 7 after running successfully through tests 1..6. The
reported error addresses are in the 120 MB area.

I checked that when memtest is configured to go directly to test 7 the
errors appear right away.

I have not had the chance to retest with older images but the chance
that both laptops independently developed RAM problems in the same area
seems small. I'll do more tests and file a Bugzilla report if it checks out.

I installed F16 RC2 Live, and tried to install qtparted.
It won't install because the most recent qtparted RPM is from F15 and
requires libparted.so.0, and F16 has libparted.so.1 pulled in by F16's
parted.

Karl Vogel has an interesting discussion relevant to the bugzilla growth
and management issues from the 'abrt' debate. The blog is titled "Bug
Growth is Proportional to User Growth, and Bugs are not Technical Debt":