Atomic Host/Workstation Interview for Linux Unplugged Podcast
by Dusty Mabe
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
A couple of us went on the LUP podcast this week to talk about Atomic Host/Workstation.
Check it out: https://twitter.com/jupitersignal/status/961283877883977728. We start around minute 16:20.
Dusty
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEPb6zG5c6sV89tRYPMwLb1zlS5nEFAlp+HAcACgkQMwLb1zlS
5nFxmg/+MR/FjNQBwcx9HfhHY25wGlOYLeIaADUJGZNVIKvCoVzDvnfZGEqivsQ2
kKnk2yxYkPwWaJuzUEQDh3WYHlE19Sbb4ABxwexbd4nU1i0vGlLAJrAGVwUoZdcG
zaiAOz6kgBoablDXhBLiZhtjCRi4uXUvqy1iUcWd5KsAGmp4mzHvqPV5LZsr5TdS
nY5LBPi8zd3MQW/3UDg/FVjHIGVYpyhNZiJ2c78vHm5VjAZYlaQMlTqHhzrQOsQe
OZ149lbwvov9plT0K4byp6bdjrW3Ld66Ft799Zw0rhteZEvOyY9qXjvvXATxQwL8
lFA6G+Z7LKcPhBPxK0XhZqy2R/IHYWYuQSilhYOvcDLwCDJpXsuIkqAOE7zmeI5N
2ioLm5UDPHZmtpIg+NKXQzr6LByA/Mi7h1y+j71B2TnwnrG77s7UeIwKxFBelbJb
I30DwOeZB8ON10NjYaF9Y2DC+GxcmtcuU0GjXvnlt0j9SEPmRWnXEcvwxMRwahDP
2x0w/iS1Jl5VLxkj2f0a/F5VuZhRcw8LZyMMQ9dvfIl5qwfOTj550GVQE+B+45c7
gXB61Xwrr0D/A9fQFiAZyBMC7Oi6ElYizmxCY7n4X296T4FP9Ccr779oSP/f+osW
mmTV1o2B1oY4cqvmXPH3G/nHnE9DK0nIJR1NS4V2jBROBuj4umQ=
=3nfn
-----END PGP SIGNATURE-----
6 years, 3 months
Package review - test builds for OpenVPN 3 Client
by David Sommerseth
Hi,
This week I've started poking at packaging pre-release builds of the new
OpenVPN 3 based client for Linux (sorry, no server support yet). I've started
a Copr build/repo for it and I'd appreciate some help reviewing the packaging
and otherwise hints (or pathces) how to improve things.
You'll find everything here:
<https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/>
Now, beware that this client is still under heavy development and is not ready
for a full release yet. Once lacking features and the most critical or
annoying bugs are sorted out, we'll tag the first beta release.
Since it is under heavy development ... it is not ready for production yet.
But I have enabled it on a server, to test the long-term stability of it.
And a final warning ... This client is _very_ _different_ from the far more
common openvpn-2.x series. It is different in almost every aspect. The only
thing they have in common is that the OpenVPN wire protocol is essentially the
same and compatible (it can connect to OpenVPN 2.x servers) and the
configuration files will in most cases work just fine (as long as unsupported
options in OpenVPN 3 is not used).
If you have any questions or comments, feel free to reach out!
--
kind regards,
David Sommerseth
OpenVPN Inc
6 years, 3 months
[HEADS UP] poppler-qt4 going away
by David Tardon
Hi,
The latest release of poppler, 0.62.0, drops the Qt4 frontend. As there
are still 7 packages in Fedora that use it, I'll revert that change to
give these packages more time to get ported--or finish porting--to Qt5.
The "grace period" will end before F29 branch-off. The affected
packages are:
* diffpdf
- apparently not OSS anymore, so an update is unlikely
* kbibtex
- port to KF5 is in progress
* krop
- uses python-poppler-qt4
- unknown status
* ktikz
- port to KF5 is in progress
* python-poppler-qt4
- there is a Qt5 port at https://github.com/wbsoft/python-poppler-qt5
- btw, the project has moved from Google Code to
https://github.com/wbsoft/python-poppler-qt4 and the Fedora package
is a few releases behind
* qcomicbook
- 0.9.1, pushed to master yesterday, is ported to Qt5 :-)
* qpdfview
- builds both Qt4 and Qt5 version
* tellico
- 3.x is ported to KF5, but it's not in Fedora yet
- btw, the current version FTBFS because it depends on tcp_wrappers
D.
6 years, 3 months
glibc, riscv64, multilib, /lib64 etc
by Richard W.M. Jones
It looks as if upstream RISC-V / glibc teams settled on some exciting
new paths to use for libc.so.6:
https://sourceware.org/ml/libc-alpha/2018-01/msg00969.html
In short, on normal 64 bit hardware which is all we really care about,
it'll use /lib64/lp64d/libc.so.6.
For Fedora we've settled on supporting only RV64GC as a baseline,
which means we don't care about hardware which lacks floating point,
nor 32 bit-only hardware since that is likely to be embedded and too
small to run Linux (32 bit embedded hardware is best served by
cross-compilers). Also because this is a new architecture there is no
legacy of 32 bit binaries that we need to run.
It's possible to change this by building glibc with
./configure --libdir=/lib64 [etc]
but it seems that /lib64/lp64d/ is still the default search path
(/lib64 is not searched) even when configuring it like that, so it's a
bit broken.
The question is how does this impact Fedora? I'm fairly sure we
don't want to change most libraries so they put stuff in /lib64/lp64d/
nor do we want to change %{_libdir} on this one architecture.
We could do a downstream patch.
We could try to change upstream, but this is all now burned into the
glibc 2.27 ABI so it's a bit complicated.
It's possible to use /usr/lib only on riscv64 (isn't that how s390x
works too)?
Any thoughts?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
6 years, 3 months
Re: glibc, riscv64, multilib, /lib64 etc
by Carlos O'Donell
On 02/08/2018 06:51 AM, david.abdurachmanov(a)gmail.com wrote:
>> We could do a downstream patch.
>
> This would be a minimal patch based on quick look into glibc code. We
> could force it to act as, e.g AArch64. I worry, that this would be
> custom from what is expected in RISC-V software ecosystem. If we stay
> with /lib64/lp64d/ then we probably need to do more fixing in packages,
> because I doubt everything is using %{_libdir}.
>
> Alternative being discussed right now at #fedora-riscv is to use
> symlinks, e.g. /usr/lib64/lp64d -> /usr/lib64 like we have /lib64 ->
> /usr/lib64
>
> If we can solve this issue with symlinks, then I would vote for that.
> Then we don't need to do a lot of fixing and we sorta have what's
> expected by glibc, or/and in general RISC-V software ecosystem.
I see two issues at hand:
(a) RISC-V software ecosystem compatibility.
(b) Technical implications and ABI compatibility.
In regards to (a), I agree completely with David, that deviating
from the RISC-V software ecosystem is going to cause adoption problems.
We should avoid changing what upstream has chosen. Symlinks should
solve the issue, and if they do not then that's a bug in the dynamic
loader and someone should immediately file the bug and the Fedora
glibc team will fix it.
In regards to (b), there are two very important distinctions to make:
(1) What is the path to the dynamic loader?
(2) What is the path to shared libraries?
Firstly, (1) is an ABI atrifact that all 3rd party libraries will
have encoded into the binaries PT_INTERP program header entry, and
for binaries compiled with an upstream the official path is listed
here:
https://sourceware.org/glibc/wiki/ABIList#RISC-V
Surprisingly it is /lib. So this means that rtlddir is /lib, and
the dynamic loader is uniquely placed in /lib *even though* it
is a 64-bit dynamic loader.
We *must* *not* deviate from this in Fedora, and this path must
exist to the loader, but it can be a symlink.
Secondly, (2) is all the libraries, and these we have much more
flexibility, we can really put them wherever we want, the DSO's
DT_NEEDED entries are SONAMES which are searched by our own loader
and since we control those search paths we could make things
work like we expect them to with all libraries in /lib64.
However, the upstream community has chosen /lib64/lp64 as the
location of the shared library directory e.g. slibdir, and that
means 3rd party binaries could have hard coded dlopen paths that
try to open specific libraries e.g. dlopen /lib64/lp64/libfoo.so.0
and if we don't at least symlink that path it will fail. Likewise
3rd party binaries may also use DT_RPATH and DT_RUNPATH to specify
specific search paths which may be based on /lib64/lp64 e.g.
/lib64/lp64/mozilla/plugins.
In summary:
- We must minimally provide a symlink for /lib/ld-linux-riscv64-lp64d.so.1
- We must minimally provide a symlink for /lib64/lp64d
- As Fedora glibc team lead I'm OK with symlinks.
I'm happy to see both of these symlinks in glibc.spec point to
wherever we as a community decide we want to see things.
--
Cheers,
Carlos.
6 years, 3 months
Re: cmake, mc unresponsive packagers
by Tomasz Kłoczko
On 8 February 2018 at 12:12, Jindrich Novy <novyjindrich(a)gmail.com> wrote:
> Hi Tomasz,
>
> Haven't I granted you commit access and co-maintenance rights few days ago
> for mc?
>
In prv email you asked me "Do you wish to become mc maintainer?" and you
should have my positive reply on this question.
Because in this email you've mention that my email landed in you spam
folder I've send you yet another prv email asking for reply or action.
On non of those two emails I had replies (pub or prv).
I did not receive any Fedora notification and at the moment
src.fedoraproject.org is currently unavailable (maintenance?).
kloczek
--
Tomasz Kłoczko | LinkedIn: *http://lnkd.in/FXPWxH <http://lnkd.in/FXPWxH>*
6 years, 3 months