Hi,
Apache Arrow 10.0.0 has been released.
At present nobody is using libarrow except Ceph. (Which I am the maintainer
of.)
I will be rebasing libarrow to 10.0.0 within the next couple of days.
--
Kaleb
Hi,
the compilation of the package vdr-epgfixer fails on rawhide with the message [1]
...
install -D libvdr-epgfixer.so /builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/usr/lib64/vdr/libvdr-epgfixer.so.2.6.3
install -D -m644 po/fi_FI.mo /builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/usr/share/locale/fi_FI/LC_MESSAGES/vdr-epgfixer.mo
install -D -m644 po/pl_PL.mo /builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/usr/share/locale/pl_PL/LC_MESSAGES/vdr-epgfixer.mo
cp: not replacing '/builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/etc/vdr/plugins/epgfixer/blacklist.conf'
cp: not replacing '/builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/etc/vdr/plugins/epgfixer/charset.conf'
cp: not replacing '/builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/etc/vdr/plugins/epgfixer/epgclone.conf'
cp: not replacing '/builddir/build/BUILDROOT/vdr-epgfixer-0.3.1-26.20180416git354f28b.fc39.x86_64/etc/vdr/plugins/epgfixer/regexp.conf'
make: *** [Makefile:132: install-conf] Error 1
How can i fix this ?
[1] https://kojipkgs.fedoraproject.org//work/tasks/2669/103932669/build.log
Regards
Martin
Hi all,
I've multiple reports of FTBFS in the packager-dashboard, but I can
see many of the packages are being built fine in koschei/koji.
Is there a known issue on refreshing koschei data?
Kind regards,
Mikel
https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
The new PatternFly-based UI has been developed by the Anaconda team
for some time now and we would like to make it available for users of
Fedora to enhance and modernize installation experience. As the first
step in this user adoption process, we are targeting Fedora
Workstation only.
== Owner ==
* Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
* Email: jkonecny(a)redhat.com
* Name: Fedora Workstation SIG
* Email: desktop(a)lists.fedoraproject.org
== Detailed Description ==
The Anaconda team has been working on a new web-based UI for the OS
installer for some time. We would like to give users the fruits of our
work and get feedback so that we know what we need to improve or where
we should focus.
To make the adoption as painless as possible, the Fedora Workstation
was chosen as the first target so we have better control over the
environment and can have a focus. Also, Fedora Workstation has a
smaller featureset than other installation media. The adoption for the
other media later is planned too, but the exact date will be based on
feedback and our capacity allowance.
=== What will '''not''' change with the new Web UI? ===
The new UI will mostly use already existing functional code (some
modifications are necessary), so the stability should be similar. The
Anaconda specific kernel boot parameters are also staying almost
unchanged. The Anaconda team aims to reduce functionality that is not
used but still put a maintenance burden on the team. This should
result in much easier future extensions and stability of the
installer. The current approach is to start from what is known to be
required and used, then add future features based on the feedback.
=== What is going to change with the new Web UI? ===
The new web UI is not just a change of the UI technology, which is
based on the React and Cockpit framework, but also a complete overhaul
of the user experience. The new UI is trying to be easier to use by
removing most of the complexities but still leaving possibilities to
do everything you might need to do. We are trying to achieve a state
where even users who don’t have previous experience with the Linux
operating system will be able to do the installation smoothly.
List of what is part of the new UI:
* Wizard solution instead of hub and spoke
* New welcome screen to select language (will be preselected from a
language configured in system)
* Timezone and date configuration
* Disk selection
* Guided partitioning
* Review configuration
* Installation progress
* Build-in help
Let’s go over the important sections from the UI.
==== Use of wizard ====
Anaconda was a hub&spoke solution where users entered spoke to
configure an aspect. The benefit of this solution is that you can skip
what you don’t need. However, the drawback is that it’s much more
information at once and harder to use when you are not familiar with
what you need. For that reason, the team decided to go with an easier
to use solution, the traditional wizard. See here for more details
https://communityblog.fedoraproject.org/anaconda-is-getting-a-new-suit-and-…
.
==== Guided partitioning ====
The current (GTK) Anaconda UI approach is to have three types of partitioning.
* Automatic - do everything automatically
* Custom - you can do everything with top-down approach where users
work on mount points and specified what technology they want to use
and how
* Blivet-gui - added later as bottom-up approach which enables users
to create the partitioning stack themselves manually
These methods are giving great freedom but each of these has its
issues. For automatic, the issue is almost no customizations and not a
clear output. For custom and blivet-gui, you need to understand the
Linux storage really well to know what you are doing, which could be
intimidating.
Because of those issues, we decided to choose another approach, which
we are calling guided partitioning. This type of partitioning is
giving users paths with explanations of what will happen but does not
overload them with too many options at once. These paths could be then
customized. This solution was taken as the best compromise between the
automatic (no customization) and custom/blivet-gui, which was too
heavy and hard to maintain.
We will provide the recommended solution and improved customization
based on the users feedback. However, in case someone is not happy
about the recommended solution, we are going to provide a way to guide
users, to create their partitioning themselves (with a tool of their
choice) and then tell Anaconda how to use it. This method could be
also used for easy re-installation of the existing system and we are
planning to improve the experience in the future even more.
==== Build-in help ====
Another pain point of the current UI is problematic help content.
Currently, it’s a button that will show a lot of text from the
documentation, which might be misleading because it’s not part of the
feature development. To improve the state, the help side panel was
added, which will provide specific help for what the user wants to
know directly in a UI. For example, if you are in the guided
partitioning screen you can find a link (blue text) with “learn more
about the…” and after clicking on this you will find details about the
given guided path. Another benefit of the new help solution is that it
is part of the source code so it changes with the feature work and
could be localized (harder to achieve before).
==== Changes not directly related to UI ====
The Anaconda team is in contact with Fedora Workstation SIG and
actively working with them to get the best user experience for users.
Together, we agreed on building the approach with the support of Gnome
Initial Setup as part of the Fedora Workstation Live environment,
which will prompt you for language and keyboard layout. Configuration
from the system is then used by Anaconda. This way, Anaconda doesn't
need to ask a second time for language (maybe just confirmation) and
keyboard layout which will be converted from the live system into the
installed system. This should result in a much better user experience.
=== Additional information ===
* We are not planning to add support for spins with this change, they
will use the existing GTK UI.
* We don’t support remote connections to the WebUI yet.
== Feedback ==
Currently we mainly discuss this with Fedora Workstation SIG and have
their support for this change. We also have feedback from our preview
builds https://fedoramagazine.org/anaconda-web-ui-preview-image-now-public/
. The feedback was mostly positive even though there are some
concerns.
Other than that we also reached to Fedora QE team and [[User:Mattdm|
Matthew Miller]] and more.
For more details about the feedback here are some tickets:
* https://pagure.io/fedora-workstation/issue/362
* https://pagure.io/fedora-workstation/issue/366
* https://pagure.io/fedora-workstation/issue/367
* https://pagure.io/fedora-workstation/issue/368
* https://pagure.io/fedora-workstation/issue/371
* https://pagure.io/fedora-workstation/issue/375
* https://pagure.io/fedora-workstation/issue/377
* https://github.com/rhinstaller/anaconda/discussions/categories/web-ui
== Benefit to Fedora ==
Fedora Workstation installation will have a more comfortable and
better user experience, especially for the new-to-distro users. We are
also targeting to have a consistent look and feel with Cockpit and
Image Builder projects, so that users might be more familiar with the
new Anaconda.
By this, we would be more aligned with Fedora Workstation SIG goals of
simple and easy-to-use solutions, and hide the complexities to make
the installation experience more robust.
It should be easier for users to reinstall the existing system.
It will also allow the Anaconda team to make the extensions to the UI
faster than it was before and should be less prone to errors compared
to the current UI.
== Scope ==
* Proposal owners:
** Anaconda team
** Fedora Workstation SIG
* Other developers: Should not have impact out of the Fedora
Workstation Live environment.
* Release engineering: Will be added
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: TBD
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
Standard installation testing of Live installation always before. We
already reached the Fedora QE team to discuss an impact on them and
ideally set the test day for more comprehensive testing with more
details.
Steps:
* Download the ISO image (not yet available - WIP)
* Start a VM with this ISO image
* Run the installation
* See journal log and/or browser console in case we missed error in the Anaconda
Bugs should be filed to [https://bugzilla.redhat.com/ Red Hat
Bugzilla] on the Anaconda component.
== User Experience ==
Installation of the system should provide a much better and more
polished user experience. Compared to the current UI users should be
fine without the familiarity of the complexities of OS installation.
== Dependencies ==
None packages should be impacted by this change. The current GTK UI
will still be available for other uses.
== Contingency Plan ==
* Contingency mechanism: Return back to the current GTK UI by changing
packages to build the ISO.
* Contingency deadline: Beta freeze
* Blocks release? No, we can ship without the new web UI
Another solution for the contingency plan which we would like to have
is support for the current GTK UI as a second UI on the same Live ISO.
That should be doable easily and if the new UI would be really a
blocker for someone, they can provide us feedback and until resolved
use the GTK UI instead.
== Documentation ==
Documentation will be expected especially for custom partitioning
replacement but not only that.
== Release Notes ==
--
Aoife Moloney
Product Owner
Community Platform Engineering Team
Red Hat EMEA
Communications House
Cork Road
Waterford
Hi folks! Just wanted to drop a note for anyone who noticed their
Rawhide updates stuck in gating for an unusually long time
yesterday/today.
This is mainly due to the mass rebuild. Merging it in (which was done
without sending anything in it through openQA testing) resulted in two
separate problems:
1. Some GNOME packages were inadvertently bumped to 45-alpha early, as
the changes were checked into git but had not been built; this caused
dependency issues, then when we tried building the remaining packages
at version 45-alpha to see if things would work OK with a consistent
set of packages, we found a bug which made the tests fail and
necessitated untagging everything back to 44:
https://gitlab.gnome.org/GNOME/mutter/-/issues/2918 .
2. The rebuilt PackageKit was broken because of a change in glib, and
needed a backport of https://github.com/PackageKit/PackageKit/pull/643
to work properly again.
These were complicated by a third problem showing up in the middle: a
new build of brltty had some internal dependency issues, and needed to
be untagged.
All of these issues caused test failures for *every* Rawhide update
tested after the mass rebuild was merged (in the first case) or the
brltty update landed (in the third case). It took several hours to get
them all unpicked and the fixed PackageKit landed, then I re-scheduled
the failed tests on all other updates (but I did this a bit wrong for
some of them, so they failed again, and I had to re-run them again an
hour or so ago).
I'm also fighting a bit with Koji giving 404 responses for the f39-
build repo more often than it usually does, but I hope to have tests
for all updates passing (assuming the update itself has no problems)
within the next hour or two.
For the next go-round, it might be good to use the relatively new
ability we have to schedule openQA tests on a side tag to test the mass
rebuild *before* it's merged, I'll check with releng if that is
feasible.
This is also the second or third time gating has been disrupted by a
broken update that wasn't in the critical path and so didn't go through
gating itself. I'm considering rejigging the
critpath/bodhi/greenwave/openqa industrial complex (again) so we
also/instead test everything that goes into the environments openQA
tests (Server, Workstation, and KDE), even if it's not "important" in
itself. Bad deps in *anything* in the environment can break the tests
because they prevent `dnf update` from succeeding at all, so the
updated packages never get installed (I actually think dnf-5 may be
being more 'strict' than dnf here, too, and exposing problems that were
previously not causing test failures, but I'd have to check that). This
would be some fairly major surgery, though (and increase the load on
openQA).
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@fosstodon.org
https://www.happyassassin.net