FWI, am still having issues rebuilding rpm due to path
mismatches between RH file layouts in the rpm and where the
opensuse spec file is looking for things.
I had hoped that rpm-config-suse might hold the config for
building the rpm with opensuse paths, but this hope was dashed.
Maybe I should file a bug against rpm-config-suse? I dunno?
*Please forward to anyone potentially interested*
In the wake of the post survey discussions, a bunch of volunteers have
risen to the challenges of improving diversity, knowledge transfer and
cross-community bonds: https://en.opensuse.org/openSUSE:Newscom
We feel like a bi-weekly newsletter might work for that, to be served on
our web platforms and shipped in the form of a mobile screen friendly
newsletter, available in the most spoken languages in the community (for
starters: Spanish, Indonesian, Brazilian Portuguese, Russian) and
broadcast across all information channels available.
Unlike its glorious ancestor
(https://en.opensuse.org/Archive:Weekly_news_99) the newsletter will
have both a cultural and a technical facet. You'll learn more about the
former in our upcoming call for participants, but I'd like to ask you
something about the latter: would some of you -- I have in mind
contributors to 101.opensuse.org, package maintainers and Heroes -- be
interested in, respectively:
- being advertised in our first issue (to fix ideas: we could write an
article about 101.opensuse.org and encourage people from these
communities to participate as either maintainers, mentors or mentees)
- having their package spotlit, simply to make it more visible or
attract new maintainers
- highlight key areas in our infrastructure, platforms and activities
that could benefit from more volunteers.
Do let us know!
2 days ago, Linux Unplugged published a podcast where they reviewed
https://linuxunplugged.com/387 (Review starts at 38:40)
The review was not as positive as I expected and it contains some general
remarks, so it makes sense to discuss it on project, and not on factory.
We may not agree with the remarks and findings, but we should at least listen
to them and ask ourself, how we can improve.
I try to summarize the various points for improvement (with my own words)
Website and download
It was noted that the download of images does not work under Chrome, so they
had to switch to Firefox
The section for live-images was considered 'confusing' as the hints lead to
the impression that not the full TW experience is possible (should not be used
for installation or upgrade of TW) - or that it may not work at all (limited
amount of drivers, may not run on all hardware).
-> What is the limiting factor to include more drivers in the images?
-> How can the live media be enhanced for full installation capabilities?
(enable online repos and pull packages from there?)
While the first power-on experience as well as the new partitioning tool was
perceived very positive, the installation process itself had several kinks:
- The reviewer is working on a Dell system with 4k screen resolution. The
installer is not properly scaling and shows all icons very tiny (complete EULA
fits on the screen). At the same time, there are some issues with the touchpad
(around minute 46:00), it is hardly possible to click a button.
-> Do we have a problem with 4k screens?
- setup of WIFI during installation 'is really old school' as one has to jump
between different tabs to set it up. And, finally, the WIFI setting is not
taken over to the installed system, so one has to enter it again (and he hit a
known Plasma-bug by this https://bugs.kde.org/show_bug.cgi?id=389052 )
-> can the WIFI setup be done on a single page?
-> can the wifi settings be transferred to the installed system?
- there was some confusion around the activation of online repositories during
installation from DVD. It is unclear where it is used or necessary for.
-> a clarification that enabling the online repositories gives a wider variety
of desktops and additional software should be included
-> this hits for some parts the recent discussion if we can include repos like
packman right at installation time
-> If I remember correctly, a TW DVD with online repos enabled installs only
if no new snapshot was released. Enabling the online repos on a DVD install
pulls most packages from the repository instead of the DVD. This is clearly
not a smart move, and I would consider this as bug. The reviewer had actually
the same complaint.
Installation of software
- After installation the reviewer obviously ran into severe performance
problems (where it was not clear to me if this was coming from Intel Graphics
or from free Nvidia driver). So he tried to install proprietary NVidia driver
and had the issue that his graphics card was mentioned nowhere and he was
unsure which driver to install ('this is managed on Fedora/Ubuntu with a
checkbox, Arch installs one additional package'). In the istallation process,
'YaST hangs at 64% for ages' and he was uncertain whether to kill the process.
-> can we improve the detection of hardware to recommend the right proprietary
driver? I cant comment on how other distros do it, but it looks like this was
- the installation of additional proprietary software (slack) obviously via
snap was not as easy as expected. I have a personal opinion on snap and
flatpack, but these formats are more to come, as a cheap alternatve if no
native packages are available.
-> is there a point where we can/need to improve the snap/flatpack support?
In general the YaST Softwaremanagement was seen as quite old style ('like we
did it 7/8 years ago).
As stated in the introduction, we do not need to agree with all findings, but
we should listen to them. Some of the points, esp. during installation, come
up same or similar in Leap. With 15.3 ahead, we should look into this and
check if we can improve this.
I would recommend to anybody to listen to the review, and see if we can
improve. The just-released community survey seems to have some of the same
points (I did not read it in detail so far), like finding documentation (not
only for Nvidia cards)