Hi everybody,
While working on packages of the Stewardship SIG, I again came across
another package that is in dire need of attention, while its main
admin seems to be AWOL (even though the email address associated with
his FAS account is a Red Hat one):
- no bodhi updates in 4 years [0]
- no bodhi comments in 2 years [0]
- no koji builds in 4 years [1]
There's also been no response to security issues on bugzilla,
including CVE-2016-6346, CVE-2016-6347, CVE-2018-1051, CVE-2016-9606,
CVE-2016-6345, CVE-2016-6348 - all of which are filed against the
resteasy package, which is, entirely by coincidence (*sigh*), exactly
the package that we need fixed for some Stewardship SIG packages.
Since it looks like he's not been contributing to fedora in about 2-4
years, I will initiate the non-responsive maintainer process with
FESCo if I don't get any negative feedback within a week.
Fabio (decathorpe)
[0]: https://bodhi.fedoraproject.org/users/vakwetu
[1]: https://koji.fedoraproject.org/koji/userinfo?userID=2030
Dear all,
You are kindly invited to the meeting:
Modularity Team (weekly) on 2019-07-09 from 15:00:00 to 16:00:00 UTC
At fedora-meeting-3(a)irc.freenode.net
The meeting will be about:
Meeting of the Modularity Team.
More information available at: [Modularity Team Docs](https://docs.pagure.org/modularity/)
The agenda for the meeting is available as flagged tickets [in the Modularity repository](https://pagure.io/modularity/issues?status=Open&tags=Meeting).
Source: https://apps.fedoraproject.org/calendar/meeting/9480/
I have a similar problem with the proposed package pveclib. I my case I
have a data only libraries. I can eliminate the rpmlint error by forcing a
link to -lc But I am not sure the the appropriate solution.
see https://bugzilla.redhat.com/show_bug.cgi?id=1725924
>
> ---------- Forwarded message ----------
> From: Florian Weimer <fweimer(a)redhat.com>
> To: "Miro Hrončok" <mhroncok(a)redhat.com>
> Cc: devel(a)lists.fedoraproject.org, Marcel Plch <mplch(a)redhat.com>
> Bcc:
> Date: Mon, 08 Jul 2019 15:25:27 +0200
> Subject: Re: rpmlint: shared-lib-without-dependency-information (parts of
> Python stdlib)
> * Miro Hrončok:
>
> > On 05. 02. 19 19:04, Miro Hrončok wrote:
> >> I've just spotted these when working on Python 3.8.0a1. This happens
> >> on 3.7 as well since GCC 9:
> >>
> >> python3-debug.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> contextvars.cpython-37dm-x86_64-linux-gnu.so
> >> python3-debug.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
> >>
> >> python3-libs.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> contextvars.cpython-37m-x86_64-linux-gnu.so
> >> python3-test.x86_64: E: library-not-linked-against-libc
> >> /usr/lib64/python3.7/lib-dynload/_
> testimportmultiple.cpython-37m-x86_64-linux-gnu.so
> >>
> >>
> >> (Note that there are plenty of other extension modules that do not
> >> raise this error.)
> >>
> >> This doesn't happen with latest python3 built prior to the gcc update
> to 9.
> >>
> >> $ rpmlint -I library-not-linked-against-libc
> >> library-not-linked-against-libc:
> >>
> >> That isn't helpful either.
> >>
> >> I found a similar Debian thing [1] that says:
> >>
> >> > It is theoretically possible to have a library which doesn't use any
> symbols
> >> > from libc...
> >>
> >> Do I care? Should I fix something? I honestly have no idea.
> >>
> >> [1]
> https://lintian.debian.org/tags/library-not-linked-against-libc.html
> >
> >
> > We have new errors on F30+:
> >
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> contextvars.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_heapq.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> testimportmultiple.cpython-38-x86_64-linux-gnu.so
> > python38.x86_64: E: shared-lib-without-dependency-information
> > /usr/lib64/python3.8/lib-dynload/_
> testinternalcapi.cpython-38-x86_64-linux-gnu.so
> >
> > rpmlint doesn't give much info:
> > $ rpmlint -I shared-lib-without-dependency-information
> > shared-lib-without-dependency-information:
> >
> >
> > But lintian again explains the issue:
> >
> https://lintian.debian.org/tags/shared-lib-without-dependency-information.h…
> >
> > The listed shared library doesn't include information about which
> > other libraries the library was linked against. (When running "ldd
> > foo.so" ldd should report about these other libraries. In your case,
> > ldd just reports "statically linked".)
> >
> > I again think this is OK for Python extension modules.
> > Thoughts?
>
> It depends on the extension module. For _contextvars, it's okay because
> it does not link against anything (glibc or otherwise). Global C++
> destructors will not work because of unfulfilled weak reference to
> __cxa_finalize, but you probably do not care about that.
>
> rpmlint really should have a list of symbols from system libraries that
> need linking, otherwise there's always going to be false positives for
> such plugins. (Although extension modules could link against libpython
> on Fedora because Fedora doesn't use the fat Python interpreter, unlike
> some other distributions.)
>
> Thanks,
> Florian
>
>
>
https://fedoraproject.org/wiki/Changes/Qt_Wayland_By_Default_On_Gnome
== Summary ==
Make Qt applications to run natively on Gnome Wayland session, using
the Qt Wayland platform plugin instead of the XCB plugin which is used
for X11/XWayland. Other desktop environments already run natively on
Wayland sessions, only Gnome is excluded by Qt.
== Owner ==
* Name: [[User:jgrulich| Jan Grulich]]
* Email: <jgrulich(a)redhat.com>
* Product: Spins / Workstation
* Responsible WG: Desktop
== Detailed Description ==
Qt Wayland plugin has been available for a long time, but it hasn't
been in condition where it could be enabled by default. With Qt 5.12
the state of the Wayland plugin is much better and it's becoming more
and more reliable. It now supports all the needed protocols and has
been enabled by default for non-Gnome Wayland sessions.
With Qt Wayland on Gnome Wayland session we need to support CSD, it's
actually the only way how decorations are going to work in Qt apps
right now. Qt Wayland implements basic decorations, which really
doesn't match Gnome Adwaita theme, therefore there are new CSD being
implemented as part of QGnomePlatform.
To make Qt applications run natively on Wayland we need to modify Qt
5, specifically '''qt5-qtbase''' module, where we allow the Wayland
plugin to be used also for Gnome sessions. The new decorations from
QGnomePlatform will be used automatically once they are fully
implemented and updated in Fedora.
== Benefit to Fedora ==
Qt applications running with the Wayland plugin run generally faster
and smoother on Wayland enabled sessions like Gnome Wayland and better
support HiDPI displays (respects desktop scale) .
== Scope ==
* Proposal owners:
# Modify Qt 5 (qt5-qtbase) to not exclude Gnome when deciding whether
to use the wayland platform plugin
# Update QGnomePlatform with upcoming upstream release including
window decorations
* Other developers:
# Test and watch for regressions.
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
Run any Qt application on Gnome Wayland session and check any issues
you may see.
== User Experience ==
* Smoother font rendering compared to Qt applications using XCB plugin
* Honor display scale, better user experience on HiDPI and semi-HiDPI desktops.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Switch back default to XCB plugin.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? product No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Just a heads up that I plan to do $subject in upcoming week in rawhide.
Let me know if I should not.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
https://fedoraproject.org/wiki/Changes/CGroupsV2
== Summary ==
The kernel has had some support for CgroupsV2 for some time, and yet
no one has used it because it is not on by default. There are lots of
new features and fixes over CgroupsV1 that it is time to reveal to the
user community.
== Owner ==
* Name: [[User:dwalsh| Daniel J Walsh]]
* Email: <dwalsh(a)redhat.com>
== Detailed Description ==
Enablement of the CgroupsV2 by default will allow tools like systemd,
container tools and libvirt to take advantage of the new features and
many fixes in Cgroups V1. A lot of the functionality in VGroups V1
has been rewritten to fix fundamental flaws in its design.
The reason CGroupsV2 by default has been blocked is that the Container
tools and someone the Virtualization tools did not have support. We
believe that the time is right to try to move these tools along to
take advantage of this kernel feature. In order to begin testing these
features more widely we believe we need to have a platform like
Rawhide to test on and get others to test as well.
The main features of CgroupsV2 we would like to take advantage of in
the container world is delegation of cgroup hierarchies. Allowing
tools like podman to be able to use CGroups in rootless mode, would be
a large advance.
== Benefit to Fedora ==
Fedora is known for being a leading platform for the enablement of new
kernel functions, and this would continue its legacy. The world will
eventually move to CGroupsV2 and Fedora should lead the way.
== Scope ==
* Proposal owners:
The largest changes required to make this Change is to get containers
runtimes like RUNC to work with the change. After RUNC has support
for CgroupsV2 we need to move container engines like Podman, CRI-o,
Buildah and Moby into support CgroupsV2.
* Other developers:
We need to find other tools that have built the CGroupsV1 API into
themselves and get them to support CGroupsV2.
Known packages:
- libvirt: The team is already working on this.
- JVM: Uses Cgroups file system to check for allocated memory for
the JVM, will have to use and understand the CgroupV2 mechanism to
discover these sessings.
- Snap package does not run with CGroupV2:
https://bugzilla.redhat.com/show_bug.cgi?id=1438079
- Systemd will need to be modified to set the new default to cgroupv2
* Release engineering: [https://pagure.io/releng/issue/8509 #8509]
* Policies and guidelines:
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Any tools or scripts that an administrator used to manually configure
the CGroupsV1 will have to be modified to CGroupsV2. Luckily if these
tools took advantage of systemd interfaces they should not require
changes.
== How To Test ==
Make sure different tools that use cgroups continue to work when
booted into the new system. Make sure containers, virtual machines
and the Jave Virtual Machine still work properly. Convert the VM's of
the Container tools like CRI-O, Buildah, Podman for run on Rawhide and
make sure their test suites completely pass. Will request that the
libvirt team and JVM teams similarly change their test platforms.
== User Experience ==
We believe that at this point their will be no or very little user
experience change, unless he is an administrator looking to modify the
system Cgroups using the cgroupsfs.
One potential problem will be container images that expect to be
running in a CgroupV1 environment. Some container engines leak the
Cgroup Hierarchy into containers so that tools within the container
can look at how much memory the cgroup gives them for example. These
tools might break with the change, but they should be adjusted quickly
over time, and I don't really see a way to avoid this.
== Dependencies ==
Currently there are no known changes to the package requirements for
this change.
== Contingency Plan ==
* Contingency mechanism: If the container tools and virtualization
tools do not work at beta and do not look like they will be ready for
beta freeze, then we revert to CgroupsV1 and try again in Fedora 32
* Contingency deadline: Beta Freeze
* Blocks release? Yes
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
I've just spotted these when working on Python 3.8.0a1. This happens on 3.7 as
well since GCC 9:
python3-debug.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37dm-x86_64-linux-gnu.so
python3-debug.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37dm-x86_64-linux-gnu.so
python3-libs.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_contextvars.cpython-37m-x86_64-linux-gnu.so
python3-test.x86_64: E: library-not-linked-against-libc
/usr/lib64/python3.7/lib-dynload/_testimportmultiple.cpython-37m-x86_64-linux-gnu.so
(Note that there are plenty of other extension modules that do not raise this
error.)
This doesn't happen with latest python3 built prior to the gcc update to 9.
$ rpmlint -I library-not-linked-against-libc
library-not-linked-against-libc:
That isn't helpful either.
I found a similar Debian thing [1] that says:
> It is theoretically possible to have a library which doesn't use any symbols
> from libc...
Do I care? Should I fix something? I honestly have no idea.
[1] https://lintian.debian.org/tags/library-not-linked-against-libc.html
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok