Fedora 30 Final blocker status mail #1
by Ben Cotton
Action summary
====================
Accepted blockers
-----------------
1. https://bugzilla.redhat.com/show_bug.cgi?id=1683197
ACTION: Identify and fix issue
2. https://bugzilla.redhat.com/show_bug.cgi?id=1691832
ACTION: Upstream rhinstaller maintainers to merge pull request
3. https://bugzilla.redhat.com/show_bug.cgi?id=1691909
ACTION: gdm maintainer to identify a fix
4. https://bugzilla.redhat.com/show_bug.cgi?id=1690429
ACTION: Upstream gnome-shell developers to identify and fix issue
5. https://bugzilla.redhat.com/show_bug.cgi?id=1688462
NEEDINFO: psabata
ACTION: FESCo to provide guidance since proposed fix is applicable to
released versions and will impact dependent applications
6. https://bugzilla.redhat.com/show_bug.cgi?id=1666920
ACTION: systemd maintainers to identify and fix issue
7. https://bugzilla.redhat.com/show_bug.cgi?id=1674045
ACTION: systemd maintainers to identify and fix issue
Proposed blockers
-----------------
1. https://bugzilla.redhat.com/show_bug.cgi?id=1695297
ACTION: QA and 389-ds-base maintainers to identify root cause
2. https://bugzilla.redhat.com/show_bug.cgi?id=1695637
ACTION: QA to see if adding chkconfig to the kickstart resolves the issue
3. https://bugzilla.redhat.com/show_bug.cgi?id=1692089
ACTION: eclipse maintainer to identify and resolve dependency issues
4. https://bugzilla.redhat.com/show_bug.cgi?id=1695013
NEEDINFO: eischmann
ACTION: Reporter to verify if gnome-control-center-3.32.1-1.fc30 fixes the issue
5. https://bugzilla.redhat.com/show_bug.cgi?id=1695967
ACTION: QA to verify initial-setup-0.3.69-1.fc30 fixes the issue
Bug-by-bug detail
=============
Accepted blockers
-----------------
1. https://bugzilla.redhat.com/show_bug.cgi?id=1683197 - gdm - ASSIGNED
gdm Fails to load with "nomodeset"
Patch to systemd upstream
(https://github.com/systemd/systemd/pull/11980) does not fix BIOS
case. Further investigation is required.
2. https://bugzilla.redhat.com/show_bug.cgi?id=1691832 - anaconda - POST
NFSISO test failed on f30 (20190320)
Pull request submitted upstream
(https://github.com/rhinstaller/anaconda/pull/1937/commits)
3. https://bugzilla.redhat.com/show_bug.cgi?id=1691909 - gdm - NEW
GDM fallback from Wayland to X11 no longer works because it takes too
long to start gnome-shell (affects 'basic graphics mode' / nomodeset,
maybe other cases)
The three second timeout in gdm is too short to catch gnome-shell
failure. We need to figure out a more robust way of detecting failure
(or kick the can down the road by extending the timeout).
4. https://bugzilla.redhat.com/show_bug.cgi?id=1690429 - gnome-shell - NEW
sometimes icon not showing for eg firefox in gnome-shell overview dash
Problem is not Fedora-specific, it also occurs on Arch. An issue is
open upstream (https://gitlab.gnome.org/GNOME/gnome-shell/issues/1053)
5. https://bugzilla.redhat.com/show_bug.cgi?id=1688462 - libdnf - NEW
System upgrades involving modular content require explicit
--setopt=module_platform_id to work correctly
Spun off from BZ #1656509. According to discussions with Modularity
team we will resolve the problem using additional detection of a
platform ID from package provides (metadata). Because the change will
have impact not only on DNF but also on other components (PackageKit,
microdnf, satellite), in Fedora 29, 30, and 31 it requires a system
wide change.
6. https://bugzilla.redhat.com/show_bug.cgi?id=1666920 - systemd - NEW
iSCSI installs fail to boot since systemd-240 (Fedora-Rawhide-20181222.n.1)
Failure appeared between composes and appears to be related to systemd
change. systemd maintainers have not commented on the bug yet.
7. https://bugzilla.redhat.com/show_bug.cgi?id=1674045 - systemd - NEW
Upgrade from F29 to Rawhide (F30) hangs at end, showing "Upgrade
complete! Cleaning up and rebooting..."
Originally reported against dnf, but reassigned to systemd because
none of the reboot mechanisms seem to work.
Proposed blockers
-----------------
1. https://bugzilla.redhat.com/show_bug.cgi?id=1695297 - 389-ds-base - ASSIGNED
Upgrading a FreeIPA server from F29 to F30 broke with 389-ds-base-1.4.1.2-2.fc30
Bug only appears with upgrades, not clean installs. Still working to
identify the root cause.
2. https://bugzilla.redhat.com/show_bug.cgi?id=1695637 - appliance-tools - NEW
initial-setup doesn't start
Pull request to include chkconfig in the kickstart was merged. This
may or may not fix the reported behavior. (It probably won’t, but
maybe?)
3. https://bugzilla.redhat.com/show_bug.cgi?id=1692089 - eclipse - ASSIGNED
cannot install Eclipse
Issue seems to be related to unmet dependencies for the eclipse
package. No specific blocker criteria are mentioned
4. https://bugzilla.redhat.com/show_bug.cgi?id=1695013 -
gnome-online-accounts - NEW
Online account settings are not available
Bug appears to be fixed in 3.32.1.
5. https://bugzilla.redhat.com/show_bug.cgi?id=1695967 - initial-setup - ON_QA
initial-setup crashes with "ImportError: cannot import name
'setup_ifcfg_log' from 'pyanaconda.network'" (function was removed
from anaconda)
Initial-setup-0.3.69-1.fc30 is submitted as a fix for this issue.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
Pronouns: he/him
5 years
Fedora 30 Beta Silverblue Feedback
by Ty Young
Hi,
I didn't see a Silverblue specific mailing list and Fedora 30 is a beta
so hopefully this is right. If it isn't, where is the appropriate place?
Firstly I'd like to just say that the idea behind Fedora Silverblue is
really amazing. My understanding it's more orientated for containers and
the like however even for general desktop usage it's incredibly useful
as a recovery mechanism from things like bad GPU driver installs.
Indeed, after a failed attempt to build the driver using a guide[1] I
was left with a broken system on reboot. I then picked the lowest(first)
boot ostree boot option from within GRUB and I was back to a usable
system with the open source Nvidia drivers. No other Linux distro is
capable of doing this as far as i'm aware(or do by default anyway).
Question: is the limit of alternative ostree(s) limited to 5? I noticed
that after 5 I was reduced back to 2, both with the Nvidia GPU driver.
Can that be changed? Is there a way to rename them to automatically
rename them so it's more clear what changed?
(If you're wondering why I was build the driver it was because I missed
the bold text in the guide. Using that instead worked just fine.)
However, there are serious issues with Fedora 30 Beta Silverblue(and
maybe standard workstation?) with software repositories. On first boot,
software center will display software and updates(and even be
downloadable and installable) however and error message will popup
saying that it can't create/read/writeto a directory(I don't have the
specific text, sorry). Software repositories are listed in
gnome-software as expected.
After rebooting all the software repositories are gone and checking for
updates gives the error message saying that packagekit timedout doing a
searchbypackagename or something like that. No software repositories
show up in gnome software anymore. Gnome-software was very slow as well.
There seems to be an issue with Steam(flatpack edition) where it doesn't
run at all. It spits out a libGL error saying that:
|libGL error: failed to load driver: swrast|
even with both 64 and 32 bit drivers installed. Am I missing something here?
Flicker free boot only seems to work with the open source drivers... and
even then it has some issues. When restarting, graphical glitching can
be observed at the top of the screen followed by a brief black screen
and then the shutdown animation screen. Booting the system up using the
Nvidia driver causes the 3 square images to be misaligned so that it's
part way between the top left of the screen and the middle with no
Fedora logo which I assume is supposed to be in the middle with a logo...
And finally, I don't know who builds the Nvidia driver(probably
community like AUR?) for Fedora but could you please stop splitting the
standard Nvidia libraries and tools into different packages? I have an
OC utility which depends on:
nvidia-smi
nvidia-settings
nvidia-xconfig
but only nvidia-settings is included with the standard driver despite
both Windows including nvidia-smi and their Windows alternative to
nvidia-settings(Nvidia Control Panel) with the driver and Ubuntu
including all 3 with the driver. This isn't a case of just someone
thinking it's wrong, there is actual precedent showing that it's wrong.
In order to get nvidia-smi you need to install the CUDA package and as
far as nvidia-xconfig goes it doesn't seem to exist. nvidia-smi isn't
exclusively related to CUDA. Including it only with CUDA drivers doesn't
make any sense. Please stop doing this. It isn't right.
[1]
https://blogs.gnome.org/alexl/2019/03/06/nvidia-drivers-in-fedora-silverb...
5 years
Heads up: OpenColorIO 1.1.1
by Richard Shaw
There's no soname change and fedabidiff output doesn't look to concerning
but I'm no expert there:
[C]'method void
OpenColorIO::v1::Processor::Impl::addColorSpaceConversion(const
OpenColorIO::v1::Config&, const OpenColorIO::v1::ConstContextRcPtr&, const
OpenColorIO::v1::ConstColorSpaceRcPtr&, const
OpenColorIO::v1::ConstColorSpaceRcPtr&)' at Processor.h:96:1 has some
indirect sub-type changes:
parameter 2 of type 'const OpenColorIO::v1::ConstContextRcPtr&' has
sub-type changes:
in referenced type 'const OpenColorIO::v1::ConstContextRcPtr':
in unqualified underlying type 'typedef
OpenColorIO::v1::ConstContextRcPtr' at OpenColorTypes.h:75:1:
underlying type 'class std::tr1::shared_ptr<const
OpenColorIO::v1::Context>' at shared_ptr.h:983:1 changed:
type size hasn't changed
1 base class deletion:
class std::tr1::__shared_ptr<const
OpenColorIO::v1::Context, __gnu_cxx::_S_atomic> at shared_ptr.h:539:1
1 base class insertion:
class std::tr1::__shared_ptr<const
OpenColorIO::v1::Context, (__gnu_cxx::_Lock_policy)2> at shared_ptr.h:539:1
Anything to be concerned about? I can rebuild the dependencies
(OpenImageIO, blender, and krita).
Thanks,
Richard
5 years
Re: Package Naming Guildelines for compat-lua packages
by Robert Scheck
Hello Tomas,
On Thu, 04 Apr 2019, Tomas Krizek wrote:
> This makes it difficult to search for lua packages and preferably, there
> should be just a single naming scheme. Based on a discussion with
> maintainer of lua-lpeg and lua-mpack [2], we've agreed to use the naming
> scheme compat-lua-*
wouldn't it have been a clever alternative to use lua52-* rather a quite
unspecific "compat-lua-" to be really similar with your python2/3 example?
Regards,
Robert
5 years
Modularity question for packagers about rolling/latest/stable/master streams
by Adam Samalik
Some modules now use "latest", "stable", or "master" as stream names for
various different things. It's quite confusing and I want to fix that.
Without naming them, I see two different use cases:
1/ "for end users" — rolling stream meant for end users to consume, likely
used in projects without traditional versioning scheme, or for the latest
version that the Fedora's "cutting edge but not bleeding edge"
2/ "for hackers/preview" — pre-release or development builds not meant for
end users to use in production, but mostly for preview, experiments, or for
people who like to live dangerously
And I want a distinct name for each of those so people know what they're
about to install. The Modularity Team can't agree on this [1], so we'd like
to hear from other packagers what they think.
So the question is, do people agree there are two? Or just one? Or more?
Thanks,
Adam
[1] https://pagure.io/modularity/issue/128
PS: I know it's not always clear for packager which one to choose — for
example with project only having a master branch — but in those cases I'd
like to use packagers' best judgement to decide wether they feel its "for
users" or "for hackers/preview". I trust Fedora packagers, that's why I use
Fedora. And they know the thing they're packaging better than me. We would
of course provide guidance that would help decide if necessary.
--
Adam Šamalík
---------------------------
Senior Software Engineer
Red Hat
5 years
Package Naming Guildelines for compat-lua packages
by Tomas Krizek
(This message is a copy for fedora-devel archival purposes, original
message was rejected by mailing list and was only sent to CCed maintainers)
Hi,
there is no official package naming guideline for lua packages in Fedora
[1].
Similarly to python2/python3, there are two version of lua: lua and
compat-lua. There is currently inconsistency in the package names for
compat-lua packages. Example:
compat-lua-lpeg vs. lua-cqueues-compat
This makes it difficult to search for lua packages and preferably, there
should be just a single naming scheme. Based on a discussion with
maintainer of lua-lpeg and lua-mpack [2], we've agreed to use the naming
scheme compat-lua-*
If you're a maintainer of a lua-*-compat package, please use the new
naming scheme along with Provides for backward compatibility [3].
If anyone has the rights to edit Package naming guidelines [1], please
document the proper way to name lua and compat-lua packages.
Thanks!
[1] -
https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidel...
[2] - https://src.fedoraproject.org/rpms/lua-mpack/pull-request/2
[3] -
https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidel...
--
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869
5 years
LD_LIBRARY_PATH vs rpath and libtool
by Ingvar Hagelund
Fedora prohibits the use of rpath, ref
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_beware_of_rpath
When compiling varnish with litbool, I ensure this by the usual
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g;
s|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
However, during build and check, I need access to a library in the
build. For example, the test suite uses the binary varnishtest to
access libvarnishapi.so.2, which is not visible as the package is not
installed yet.
I have gotten around this by putting in LD_LIBRARY_PATH where I need,
but rpmlint gives me a warning on that.
Are there other possibilities to solve this?
Ingvar
5 years
DevConf.IN 2019 Inviting Speakers - CFP Open
by P J P
Hello,
The annual DevConf.IN conference is here again!
-> https://devconf.info/in/
We are glad to announce that CFP for DevConf.IN 2019 is now open!! :)
Event Dates: 2 - 3 August 2019
Venue: Selection underway - TBA , Bengaluru, KA, India.
Important dates
-> CFP closes: May 1st, 2019
-> Speaker confirmation: June 1st, 2019
-> Schedule announcement: July 1st, 2019
We cordially invite you to submit a proposal to speak at DevConf.IN 2019.
This is the third edition of DevConf.in conference where free and
open source software communities and developers meet, learn, and
hack on FOSS projects. DevConf.IN 2019 is organised and sponsored
by Red Hat Inc.
We invite speakers from various backgrounds and roles, including
developers, administrators, engineers, DevOps practitioners,
quality engineers, technical writers, project managers, and more.
If you’re a FOSS project contributor, you’re a potential speaker!
While submitting the proposal, you need to choose a theme that the
talk/workshop belongs to. Themes for this year are
* TRENDING TECH :
* AI, Machine Learning, Block Chain, IoT, Mobile.
* Storage and Networking
* Cloud Native Storage, Software Defined Storage, Storage Management,
Distributed file system, datastores, Big Data, NFV/VNF,
Fast data path acceleration, OVS/VPP and DPDK, , network debug analysis,
Software Defined Networking, OVS offload/full offload, performance benchmarking,
NFV
* Open Hybrid Cloud
* Multi Cloud, Automation, OpenStack, Kubernetes, Serverless, Microservices,
Containers, OpenShift/ PaaS, Hybrid Cloud management, Operators, CNI, Virtualization,
Kernel, Service mesh
* Developer Tools
* Container Tooling, CI/CD, DevOps, Code Editors, Cloud native IDE, CLI,
Local Development for containers, Language Runtime, Debugging/Tracing, Testing
* FOSS Community and Standards
* Community Trends, governance, licensing, contribution, Leadership Agile
* White Paper/ Academic Research
* Computer Science Engineering, New algorithms, Protocols, Experimental/Future networks,
Data Modelling, Security, Natural Language Processing-NLP
* Design
* Security
* QE
* DevOps
* Documentation
* Security/Data Privacy
These focus areas are the common and integral part of all themes
We are looking for talks and workshops which appeal to the beginner,
intermediate and advanced participant in community projects.
The CFP is NOW OPEN! Ready to submit your proposal? Visit
-> http://devconf.in/
Questions? Please write to us at <info(a)devconf.in>
Thank you.
---
-P J P
http://feedmug.com
5 years, 1 month
