Hiding the grub menu by default on single OS installs
by Hans de Goede
Hi All,
I'm working on improving the Fedora boot experience, with the
end goal being a user pressing the on button and then going
to the graphical login manager without him seeing any
text messages / menus filled with technical jargon.
IIRC we used to hide the grub-menu by default on single
OS installs, but we seemed to have stopped doing that,
for new Fedora 29 installs I would like us to start
hiding the menu by default on single OS installs again,
see:
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
The goal if this email is to:
1) Give people an advance warning about the plan to change
this so we can discuss this early on
2) See if anyone knows why we stopped doing this, I think
we may simply have stopped doing this to simplify to bootconfig
code in anaconda and because we did not always identify the
single OS case correctly, but I wonder if there were other
reasons?
Regards,
Hans
5 years, 8 months
Re: Your package doesn't build with Python 3.7
by Sérgio Basto
On Thu, 2018-06-28 at 20:41 +0200, Miro Hrončok wrote:
> sergiomb opencv
/builddir/build/BUILD/opencv-3.4.1/modules/python/src2/cv2.cpp:889:34:
error: invalid conversion from 'const char*' to 'char*' [-fpermissive]
char* str = PyString_AsString(obj);
This problem is not about new gcc flags ? or about python rebuild ? now
that I'm reading if I just add const to the code [1] will fix this
build error ?
original code here [2]
[1]
const char* str = PyString_AsString(obj);
[2]
https://github.com/opencv/opencv/blob/master/modules/python/src2/cv2.cp
p#L919
Thanks,
--
Sérgio M. B.
5 years, 8 months
F29 System Wide Change: Modules for Everyone
by Jan Kurik
= Proposed System Wide Change: Modules for Everyone =
https://fedoraproject.org/wiki/Changes/ModulesForEveryone
Owner(s):
* Stephen Gallagher <sgallagh at fedoraproject dot org>
* Langdon White <langdon at fedoraproject dot org>
All Fedora installations will have modular repositories enabled by default,
previously available, by default, only to Server Edition.
== Detailed description ==
In Fedora 28, the Server Edition debuted new modular functionality,
allowing end-users access to alternative versions of popular software. Due
to technical limitations with package-management software, it was not
available for non-Server deployments of Fedora. Beginning with Fedora 29,
all installations of Fedora will have modules available for installation
and update. This will be done by merging the `fedora-repos-modular`
sub-package back into the `fedora-repos` package.
== Scope ==
* Proposal owners:
The proposal owners need to coordinate the work of the DNF team and
release-engineering to make sure that the repo subpackage merge only
happens once the libdnf enhancements are stable. We will also need to
prepare and run a Fedora Test Day with the QA team.
* Other developers:
The DNF team is already committed to providing the necessary changes for
libdnf in Fedora 29.
* Release engineering:
#7561 [https://pagure.io/releng/issue/7561]
** List of deliverables:
All Fedora installations
* Policies and guidelines:
No alterations to packaging guidelines are required specifically for this
change
* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
5 years, 8 months
[F29 only] Dropping requirements for initscripts package from specfiles
by David Kaspar [Dee'Kej]
Hello people,
I'm working on making Fedora being able to function completely without the
'initscripts' package (hopefully) some day in the future. I have done some
cleanup in initscripts recently, and I would like to ask maintainers of
packages listed below to check if their package(s) still really need the
initscripts package to function properly (for any reason).
It seems that for many packages the requirement of initscripts is just a
leftover from past. If the package does not need the initscripts any
longer, please remove the requirement in Rawhide (F29) and forward. (Do not
backport this change into F28 or F27, it would break things.)
NOTE: In case you are depending on initscripts because of networking
scripts (ifup/ifdown, etc.), then you will need to update your specfile to
depend directly on new package 'network-scripts' (instead of 'initscripts').
I've opened bug reports for each of the packages listed here, and created a
tracking BZ for it:
https://bugzilla.redhat.com/show_bug.cgi?id=1592330
List of packages still depending on initscripts (some of them were already
fixed):
3proxy
barry
boomaga-selinux
Canna
clamsmtp
conmux
crossfire-selinux
cyphesis
device-mapper-multipath
dpm-xrootd
ebnetd-common
exim
exim-clamav
foghorn
freeipa-client
glpi
groonga-munin-plugins
groonga-server-gqtp
iipsrv
isdn4k-utils
kbd
libstoragemgmt
mailman-3
nightview-server
node
ntop
numad
omniORB
openslp-server
os-net-config
pcp
pcsc-cyberjack
pgbouncer
plymouth
ppp
pure-ftpd-selinux
ratbox-services
sagator-core
spacewalk-config
spamassassin
spawn-fcgi
sslogger
systemtap-initscript
systemtap-server
tigervnc-server-minimal
torque-mom
torque-scheduler
torque-server
trafficserver
varnish
vdsm
vhostmd
vpnc
vte
vte291
vte3
wine-desktop
xboxdrv
Thank you, and best regards! :)
David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*
RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat <http://www.redhat.com/en/about/trusted>.
5 years, 8 months
What is the criterion for Python 3.7 side tag merge?
by Miro Hrončok
The Python 3.7 rebuild in the f29-python side tag is currently:
- 2168 built
- ~170 FTBFS
- ~120 blocked by dependencies that FTBFS
Ideally, this would all get fixed before the merge, but that's
unrealistic, there are packages that are FTBFS for unrelated reasons, etc.
What is the criterion to merge the side tag?
The critpath installs fine (except stuff that cannot be installed due to
yum-deprecated vs yum collisions and gnome-software that has some broken
dependency on PackageKit).
Stuff that doesn't build and sounds important:
- ceph (also FTBFS in regular rawhide)
- libreoffice (also FTBFS in regular rawhide)
- orca (blocked by pyatspi, looking at it ATM)
- kernel-tools
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5 years, 8 months
nextcloud-client packaging help wanted
by Germano Massullo
Hello, I am the maintainer of nextcloud-client.
I am writing to ask for help in maintaining nextcloud-client.
Actually nextcloud-client is just a nextcloud themed version[1] of
owncloud-client[2].
The new nextcloud-client[3] instead is still at a very alpha state.
We used to be 5 maintainers, but after months of co-maintainers being
unresponsive, I removed them, otherwise people could think that there
are plenty of people working on the package.
The package needs to be updated to lastest owncloud-client version and
there is also the need for starting working on a new spec file for the
next generation nextcloud client [3].
Best regards
[1]: https://github.com/nextcloud/client_theming
[2]: https://github.com/owncloud/client
[3]: https://github.com/nextcloud/desktop
5 years, 9 months
python-sphinx_rtd_theme advice
by Jerry James
I somehow wound up owning python-sphinx_rtd_theme, I think probably because
I was the first person to attempt to do a build that needed it. :-)
Anyhow, I am not at all sure that I am competent to be the maintainer. I
need some advice. There is a new upstream version available, 0.4.0. I am
looking at it right now, and my attempts at unbundling fonts from this
package seem to be unraveling.
Three font families are bundled: fontawesome, Roboto Slab, and Lato. We
have all 3 of these in Fedora, but the problem is that this package wants
the web versions of these fonts, too. We have fontawesome-fonts-web, but
we do not have .eot, .woff, or .woff2 files available for the other 2
fonts, so far as I am able to determine. Since the .ttf files of those
fonts are not byte-equivalent to the ones we ship ... I'm not sure what is
safe to do here. I am not any kind of font expert.
The upstream tarball is here:
https://files.pythonhosted.org/packages/source/s/sphinx_rtd_theme/sphinx_....
Any advice on how to deal with those fonts is most welcome. Any offers
from someone more competent than me to maintain this package would be
gratefully received.
Regards,
--
Jerry James
http://www.jamezone.org/
5 years, 9 months