DevHeads.net

Postings by Przemek Klosowski

Debian and Fedora distro development

A longtime Debian developer Michael Stapelberg described his
frustrations with their distribution development environment

<a href="https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/" title="https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/">https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/</a>

Many points are spookily similar to issues in Fedora, as discussed on
this list, for instance the automation of large-scale changes,
especially as it intersects with individual packagers' autonomy.

openssl 1.1 development conflicts with compat-openssl (1.0)

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.

Which sqlite?

Currently the package 'sqlite2' provides the binary /usr/bin/sqlite,
while the package 'sqlite' provides the binary /usr/bin/sqlite3.

This results in a confusing interaction, because with sqlite package
installed, running sqlite results in a 'command not found' message and a
suggestion to install sqlite2.

I suggest renaming the binary and manpage in sqlite2 to sqlite2, and
renaming the binary and manpage provided by sqlite to sqlite.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1477740" title="https://bugzilla.redhat.com/show_bug.cgi?id=1477740">https://bugzilla.redhat.com/show_bug.cgi?id=1477740</a>

Come to think about it, do we even need sqlite2 any more? Maybe it
should be dropped?

DNF dependencies and --allowerasing

Recently, upgrading pymol was blocked because of version incompatiblity
with pymol-wxpython:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1563269" title="https://bugzilla.redhat.com/show_bug.cgi?id=1563269">https://bugzilla.redhat.com/show_bug.cgi?id=1563269</a>

The previous version is 1.8.6 and both packages are closely coupled so
they require each other's version. Pymol update to 1.9.0 is blocked
because there's no corresponding  version of pymol-wxpython.

dnf update blocked by dnf-utils

Currently the updates seem to be blocked by a conflict between yum-utils
and dnf-utils:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1542616" title="https://bugzilla.redhat.com/show_bug.cgi?id=1542616">https://bugzilla.redhat.com/show_bug.cgi?id=1542616</a>

There are ways to work around it but it's not obvious,  so in the
interest of resolving this quickly I decided to post here.

TL;DR:

dnf update --skip-broken --best   doesn't help; the only way I could
find  is:

dnf -y update --exclude=fedora-upgrade

I think an intervention from the packager of dnf-tools or fedora-upgrade
is required.

As an aside, I guessed which package needs to be excluded, but there
must be a way to discover it in a more syst

adding display authorization to other accounts is broken

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?

debug facilities

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.

Unified database for DNF

I noticed this FESCo topic:
#link <a href="https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF" title="https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF">https://fedoraproject.org/wiki/Changes/Unified_database_for_DNF</a>

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!!!)

BTRFS dropped by RedHat

The release notes for RHEL 7.4 announce that RedHat gave up on btrfs:

<a href="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html" title="https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html">https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7...</a>

Btrfs has been deprecated

The Btrfs file system has been in Technology Preview state since the
initial release of Red Hat Enterprise Linux 6.

polymake blocks system updates by strict Perl dependence

Polymake blocks system updates by strict Perl dependence:

polymake-3.0r2-1.fc25.x86_64 requires perl = 4:5.24.0

and the new perl package is tagged 4:5.24.1

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.

debuginfo updates: RFE for 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.

state of advanced audio in Fedora

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.

fedup FC20 -> FC21 update conflicts

I have a fairly standard FC20 setup which I started upgrading by

fedup --network 21 --product=workstation

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

icedtea-web-1.5.2-0.fc20.x86_64 requires
java-1.7.0-openjdk-1:1.7.0.71-2.5.3.0.fc20.x86_64

R-core-3.1.2-1.fc20.x86_64 requires tk-1

bugzilla usage trends

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.

libatasmart viability

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

clock-applet memory leak

I reported the large memory leak in clock-applet:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=952763" title="https://bugzilla.redhat.com/show_bug.cgi?id=952763">https://bugzilla.redhat.com/show_bug.cgi?id=952763</a>

(TLDR: clock-applet grows by 1GB/day when reporting weather)

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.

SSH connection problem and possible buffer overflow

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:

ssh -v serverA
...
debug1: SSH2_MSG_KEXINIT sent
Read from socket failed: Connection reset by peer

This is vexing: I can ssh to an identically configured serverB.

memtest from F17 beta DVD images

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.

Bug 750566 - qtparted won't install because it is from F15 and requires libparted.so.0, and F16 has libparted.so.1

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.

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=750566" title="https://bugzilla.redhat.com/show_bug.cgi?id=750566">https://bugzilla.redhat.com/show_bug.cgi?id=750566</a>

Re: Shared library permissions in Debian-land and Red Hat-land

On 03/24/2011 02:49 PM, Kevin Kofler wrote:

interesting blog relevant to abrt/bugzilla discussions

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

<a href="http://www.rants.org/2010/01/10/bugs-users-and-tech-debt/" title="http://www.rants.org/2010/01/10/bugs-users-and-tech-debt/">http://www.rants.org/2010/01/10/bugs-users-and-tech-debt/</a>

He makes a point that for a growing project it doesn't even make sense
to expect zero or constant bugs---instead, the challenge is how to
manage the infinite growth.

FC11 packages 'newer' than FC12

I originally reported this through bugzilla, but at Rahul's suggestion,
I am posting this to the fedora-devel.

Some Fedora 12 packages have versions that do not supersede the versions
of Fedora 11 packages, preventing a complete upgrade to FC12.