Postings by Josh Stone

License change for rust-lru_time_cache

Upstream changed [1] from GPLv3 to dual licenses, MIT or BSD, which is
now released and in rawhide: rust-lru_time_cache-0.8.1-1.fc30

[1]: <a href="" title=""></a>

License change for rust-ryu

rust-ryu-0.2.6-1.fc30 has broadened its license from just "ASL 2.0" to
"ASL 2.0 or Boost".

License change for rust-slab

rust-slab-0.4.1-1.fc29 has changed its license from "MIT or ASL 2.0" to
just MIT. The upstream change is here:
<a href="" title=""></a>

License change for rust-adler32

Upstream has updated from just BSD to BSD and zlib, reflecting the
origins of the code ported to Rust.

license change in rust-tokio-{executor,reactor,threadpool}

These three rust crates have changed from a combo "MIT or ASL 2.0"
license to just MIT.


The same change will be coming to rust-tokio-0.1.4 in this update:
<a href="" title=""></a>

rust-structopt and rust-structopt-derive license change

rust-structopt-0.2.5-1.fc29 and rust-structopt-derive-0.2.5-1.fc29 come
with a license change from "WTFPL" to "ASL 2.0 or MIT".

LLVM compatibility hazard on F24/F25

re <a href="" title=""></a>

This is an indirect consequence of the LLVM update for bug 1376213. In
the initial llvm-3.8.1-1 update, ajax enabled the Mips target, but this
was never pushed out due to unrelated build issues. Then later I found
I needed an LLVM update for s390x, so I fixed those issues too and
pushed out llvm-3.8.1-2.

Rust detects the available targets when rustc is built, and this is its
first update using llvm-3.8.1-2, so now it has picked up the Mips target
and uses Mips-related symbols.

Symbol `SSL_ImplementedCiphers' has different size in shared object, consider re-linking

I update from nss-3.19.3-1.0.fc22.x86_64 to nss-3.20.0-1.0.fc22.x86_64
this morning, and now I get this stderr output:

$ /usr/bin/stap -V >/dev/null
/usr/bin/stap: Symbol `SSL_ImplementedCiphers' has different size in
shared object, consider re-linking

The message comes from; that symbol comes from

Should I be worried about this? Do we need a rebuild of all
nss-dependent packages to clear this message?

python packages versus pydoc -k

Do we have any packaging requirements or guidelines for python modules
to behave nicely with pydoc? I've seen this break a number of times,
and sometimes the bugs I've filed have been fixed, sometimes ignored.
Before I go through another round, I'd like to know if we have (or
should have) some official policy on this.

AIUI, pydoc works by importing the named module, then displaying its
docstrings. Then "pydoc -k" does this for all modules in sys.path,
looking for the specified keyword.

OK to bump soname for a lesser-used library?

It's clear to me that library soname bumps should generally be avoided
in released Fedoras, but can it be allowed for more fringe libraries?

Specifically, I'd like to get Dyninst 8.1 into Fedora 18, which would
bump everything from ".so.8.0" to ".so.8.1". The only in-distro package
that BuildRequires Dyninst is SystemTap, which I also co-maintain and
will certainly rebuild in tandem.

If there are any out-of-distro users of our dyninst libraries, I expect
they are of the more research-oriented type who will appreciate keeping
up the version.

rawhide missed an implicit dependency for #!python


Our dtrace script in systemtap-sdt-devel starts "#!/usr/bin/python".
Usually this leads to an implicit "Requires: /usr/bin/python", but for
some reason our rawhide build did not get this.

serial kernel console vs. systemd


I'm trying to debug some kernel crashes that I'm getting in a virtual
machine running rawhide. Adding "console=ttyS0,57600 console=tty0" to
the guest kernel used to work so "virsh console my-vm" would get me all
the kernel messages. Now in this systemd world, I get *some* messages
as it runs, but not everything that dmesg shows . And I don't get
anything when the kernel actually crashes.

I've seen hints that systemd is reading the console=... parameters and
remapping them through userspace.