devel January 2019

devel@lists.fedoraproject.org

211 participants
260 discussions

Orphaning pl (SWI Prolog)
by Petr Pisar 08 Feb '19

08 Feb '19

I have no interest in maintaining pl (SWI Prolog) package and thus I'm going to orphan it. The package is a Prolog langugage interpreter with bundled various libraries and tools written in that language. E.g. an HTTP server or an interface to Java virtual machine. Upstream does a new major release roughly every year and a few bug-fix releases during the year. From packaging point of view there are few downs like: Reviewing each rebase for licenses is tiresome due the size (118 MB). Upstream does not like how it is packaged because Fedora bends it to FHS. Fedora does not like how it is packaged because it's not bended enough. There are occasional FTBFS when JVM reorganizes its files. The package should be renamed to swipl to match the upstream. The source archive is stripped down from non-free files. The pl package has two comaintainers, mef and bagnara, who did not touch the pacakge for last 10 years. The package is required when building and running these source packages: perl-Language-Prolog-Yaswi ppisar,jplesnik Can be removed. ppl bagnara,pcpa A subpackage can be disabled. python-pyswip thofmann A subpackage can be disabled. The package builds fine now and a new 8.1 release is waiting for packaging. If you want to take over a maintainership of this package, let me know and I will assign it to you. Otherwise I will orphan it next week. -- Petr

1 1

F30 Self-Contained Change proposal: Improved GRUB menu
by Ben Cotton 05 Feb '19

05 Feb '19

https://fedoraproject.org/wiki/Changes/ImprovedGrubMenu == Summary == Improve the GRUB menu by only having the default boot option for each installed operating system in the main menu, and the other options into a sub-menu. This would better organize the boot options and lead to an easier and seamless boot experience. == Owner == * Name: [[User:Javierm|Javier Martinez Canillas]] * Email: javierm(a)redhat.com == Detailed Description == The current GRUB menu is confusing, specially when multiple operating systems are installed. The Fedora boot entries are added first and then the ones for the other installed operating systems. The main menu contains all the boot entries for Fedora but only the default boot entry for the other operating systems, the non-default boot entries for the other installed operating systems are placed into a per operating system sub-menu. An example of how the GRUB menu currently looks can be found at [https://javierm.fedorapeople.org/grub2/menu/fedora_menu.png https://javierm.fedorapeople.org/grub2/menu/fedora_menu.png] This can be improved by adding a sub-menu for the Fedora non-default boot entries, as is already the case for the other installed operating systems. This will make the boot entries for all the operating systems consistent. Another improvement would be to group all the default options for the operating systems as one section, followed by another section that groups all the sub-menus for the non-default options. A tentative design made by Allan Day for the improved GRUB menu can be found at [https://wiki.gnome.org/Design/OS/BootOptions#Tentative_Design https://wiki.gnome.org/Design/OS/BootOptions#Tentative_Design] For Fedora, the boot option in the main menu will either be the selected default boot entry or if no default was chosen, the latest installed kernel. For the other installed operating systems, the boot option in the main menu will be the latest kernel as found by GRUB's os-prober script. == Benefit to Fedora == Making the menu less confusing and with better organized boot options will lead to a better user experience and make easier for users to choose the operating systems to boot. == Scope == * Proposal owners: # Change GRUB to implement the changes as described in the "Detailed Description" section. # Make sure this is all properly documented in release-notes, etc. * Other developers: # Test and watch for regressions. * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: No changes needed. == Upgrade/compatibility impact == The changes are in the grub.cfg file generated at install time by Anaconda. Users can manually enable this after an upgrade by executing gru2-mkconfig to regenerate their grub.cfg file. == How To Test == # Single OS test ## Install Fedora in a VM. ## On boot the default boot option is in the main menu and the other options (e.g: rescue boot option) are in a sub-menu. # Multi boot test ## Install Fedora on a machine which other operating system installed. ## On boot the default boot options for the operating systems are in the main menu and the other options in sub-menus. == User Experience == A simpler and easier to understand GRUB boot menu. Choosing which operating system to boot should be simpler and involve less steps. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the GRUB changes. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? None -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

4 4

Fedora 30 System-Wide Change proposal: Remove Obsolete Scriptlets
by Ben Cotton 05 Feb '19

05 Feb '19

https://fedoraproject.org/wiki/Changes/RemoveObsoleteScriptlets == Summary == Remove scriptlets which are not needed anymore (ldconfig, gtk-update-icon-cache, etc.). == Owner == * Name: [[User:ignatenkobrain|Igor Gnatenko]] * Email: ignatenkobrain(a)fedoraproject.org == Scope == * Proposal owners: Find appropriate packages and remove obsolete scriptlets. * Other developers: Package Maintainers are advised to remove scriptlets themselves or wait until Proposal Owners will do that. * Release engineering: [https://pagure.io/releng/issue/7977 #7977] (to avoid multiple rebuilds, completing this change before mass rebuild is advised) ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A * Policies and guidelines: Guidelines are already updated. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Installed F30 RPMs on F28/EL6/EL7 might not work although it is not supported. == How To Test == Install new version of package with removed scriptlets and observe that it works. == User Experience == Installation of packages are faster. == Dependencies == No specific dependencies. == Contingency Plan == * Contingency mechanism: Proposal Owners will revert changes which break specific packages when encountered. * Contingency deadline: Final freeze. * Blocks release? No == Documentation == Everything is already documented in [https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/ Packaging Guidelines]. -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

20 41

Fixing Wireguard spec file
by Germano Massullo 04 Feb '19

04 Feb '19

This [1] is the Wireguard spec file from upstream Copr repo [2]. Wireguard will be included in kernel 5.0, but meanwhile we are using it as dkms. The only problem is that at every Wireguard upgrade, a manual action is required. For example now that I have installed 0.0.20190123, I have to remove the old /var/lib/dkms/wireguard/0.0.20181218/ folder in order to let # dkms autoinstall work. Otherwise I will get a ======= # dkms status Error! Could not locate dkms.conf file. File: /var/lib/dkms/wireguard/0.0.20181218/source/dkms.conf does not exist. ======= and wg-quick service unable to start. Do you have any idea about how the Wireguard spec file could be fixed in order to avoid this action having to be runned at every package update? Thank you [1]: https://copr-be.cloud.fedoraproject.org/results/jdoss/wireguard/fedora-29-x… [2]: https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/

5 11

Strange rawhide behaviour
by Michal Schorm 04 Feb '19

04 Feb '19

Hello, I built "community-mysql" package in version 8.0.14 in rawhide. It was built on top of "libicu-devel" 63.1-1.fc30 -- 1) But when I tried to install the community-mysql package into Rawhide, I got: nothing provides libicuio.so.63()(64bit) needed by community-mysql-server-8.0.14-2.fc30.x86_64 That means, it was available in the buildroot, but not in the repository. How is that possible? The buildroot also need the exact same repository to install packages from, right? -- 2) When installed the latest icu build, I got: ackage xfsprogs-4.18.0-1.fc30.x86_64 requires libicui18n.so.62()(64bit), but none of the providers can be installed Which means, "community-mysql" was built on top of the newer library version that its dependencies. Unfortunate, however that should sooner or later fix itself, thanks to koschei rebuilding the packages. Or at some point, rawhide will undergo a system wide rebuild. Right? -- Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat --

13 23

F30 Self-Contained Change proposal: MongoDB Removal
by Ben Cotton 02 Feb '19

02 Feb '19

https://fedoraproject.org/wiki/Changes/MongoDB_Removal == Summary == Fedora has determined that the Server Side Public Licensev1 (SSPL) is not a Free Software License. Therefore, we need to drop MongoDB from Fedora. == Owner == * Name: [[User:panovotn| Patrik Novotný]]  * Email: panovotn(a)redhat.com -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

18 36

Mass rebuild - emacs broken
by Richard W.M. Jones 01 Feb '19

01 Feb '19

emacs isn't installable at the moment, so any package that needs emacs fails to build, eg: https://koji.fedoraproject.org/koji/taskinfo?taskID=32380321 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top

5 7

Can't figure out how to build flatpaks
by Pete Walter 01 Feb '19

01 Feb '19

Hi, I've noticed that someone created a flatpak build for one of my packages (feedreader), but it's horribly out of date: flatpak has 2.5.1 vs rpm has 2.7.0. I've been trying to update the flatpak build, but not much luck here. The documentation is pretty verbose, but seems to miss some crucial steps and nothing really works. I've been following https://fishsoup.net/misc/fedora-docs-flatpak/flatpak/tutorial/ Specifically, I've typed the following commands: # dnf install flatpak-module-tools fedmod $ fedpkg clone modules/feedreader $ cd feedreader $ fedmod fetch-metadata Up until here everything seems to check out and download correctly, but then when I do: $ flatpak-module local-build --install 2019-01-31 17:11:52,388 - MainThread - moksha.hub - WARNING - Cannot find qpid python module. Make sure you have python-qpid installed. BUILDING MODULE =============== Traceback (most recent call last): File "/usr/bin/mbs-manager", line 11, in <module> load_entry_point('module-build-service==2.12.2', 'console_scripts', 'mbs-manager')() File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line 189, in manager_wrapper manager.run() File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 417, in run result = self.handle(argv[0], argv[1:]) File "/usr/lib/python3.7/site-packages/flask_script/__init__.py", line 386, in handle res = handle(*args, **config) File "/usr/lib/python3.7/site-packages/flask_script/commands.py", line 216, in __call__ return self.run(*args, **kwargs) File "/usr/lib/python3.7/site-packages/module_build_service/manage.py", line 154, in build_module_locally username, handle, str(stream), skiptests, optional_params) File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", line 386, in submit_module_build_from_yaml return submit_module_build(username, None, mmd, optional_params) File "/usr/lib/python3.7/site-packages/module_build_service/utils/submit.py", line 486, in submit_module_build mmds = generate_expanded_mmds(db.session, mmd, raise_if_stream_ambigous, default_streams) File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py", line 345, in generate_expanded_mmds current_mmd, default_streams, raise_if_stream_ambigous) File "/usr/lib/python3.7/site-packages/module_build_service/utils/mse.py", line 276, in get_mmds_required_by_module_recursively .format(base_module_choices)) module_build_service.errors.UnprocessableEntity: None of the base module (platform) streams in the buildrequires section could be found error: mbs-manager build_module_locally failed error: log: None From this error message, it's unclear to me what I need to install. feedreader.yaml has: - buildrequires: flatpak-runtime: [f29] requires: flatpak-runtime: [f29] so I've tried to do 'dnf install flatpak-runtime' but the package doesn't seem to be available. Next, I thought I'd try building it in koji. Not sure how to do that, the docs are fairly vague, mentioning 'git push origin master' but I don't have anything really to push, the existing git doesn't seem to refer to package versions or anything. I figured that maybe it somehow magically connects it to dist-git rpms/feedreader and gets the sources there so I've tried just 'fedpkg module-build' without pushing anything to modules/flatpak, but that fails again with the familiar missing buildrequires error: $ fedpkg module-build Submitting the module build... Could not execute module_build: The build failed with: None of the base module (platform or bootstrap) streams in the buildrequires section could be found Is the flatpak building actually working for anyone? What am I doing wrong? How do I specify what version to actually build? Thanks, Pete

2 2

F30: Self-Contained Change proposal: Firefox Wayland By Default On Gnome
by Ben Cotton 01 Feb '19

01 Feb '19

https://fedoraproject.org/wiki/Changes/Firefox_Wayland_By_Default_On_Gnome == Summary == Firefox is going to run natively on Gnome Wayland session and won't use XWayland/X11 Gtk+ backend. This change affects Gnome only and won't be enabled for other Wayland compositors (KDE Plasma, Sway). == Owner == * Name: [[User:stransky| Martin Stransky]] * Email: <stransky(a)redhat.com> * Product: Spins / Workstation * Responsible WG: Desktop == Detailed Description == Firefox with native Wayland backend has been available for last two Fedora releases as an optional package. It grown over the time and we can deploy it now as a default to bring all Wayland benefits to Fedora users. == Benefit to Fedora == Running Firefox natively on Wayland is generally faster and smoother on Wayland enabled sessions like Gnome Wayland and better supports HiDPI displays (respects desktop scale) . == Scope == * Proposal owners: Firefox already uses Wayland as a default backend on Fedora 30 / Gnoma Wayland session. * Other developers: N/A (not a System Wide Change) * Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) ** List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == Run Firefox on Gnome Wayland session and check any issues you may see. == User Experience == * Faster Firefox run on Gnome Wayland session * Smoother font rendering compared to non-Wayland Firefox version * 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 X11 backend. * Contingency deadline: Beta Freeze * Blocks release? No * Blocks product? product No == Documentation == * Mozilla Firefox Wayland Bug tracker: https://bugzilla.mozilla.org/show_bug.cgi?id=635134 * Mozilla release calendar: https://wiki.mozilla.org/RapidRelease/Calendar -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis

7 8

[modularity] Policy change: module defaults changes & Fedora Changes
by Adam Samalik 31 Jan '19

31 Jan '19

The Modularity Team has published an updated policy regarding changing module defaults and submitting Fedora Changes [1]. Simplified summary: instead of: "Packagers must submit a Fedora Change when changing module defaults." it now says: "Packagers should submit a Fedora Change when changing module defaults based on their best judgement." That brings it much closer to how we handle major changes in traditional packages. Cheers! Adam [1] https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-def… -- Adam Šamalík --------------------------- Software Engineer Red Hat

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
26
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2019