devel October 2020

devel@lists.fedoraproject.org

226 participants
416 discussions

git push permission denied
by Neal Becker 10 Feb '21

10 Feb '21

I just had to setup a new machine, and new ssh keys. I visited https://admin.fedoraproject.org/accounts/user/edit/xxxx I chose my new id_rsa.pub to upload. But I get: git push --verbose Pushing to ssh://nbecker@pkgs.fedoraproject.org/mercurial Permission denied (publickey). fatal: The remote end hung up unexpectedly Hints?

4 5

our containers with alias vim=vi
by clime 10 Feb '21

10 Feb '21

Hello, could Fedora and CentOS containers for docker and podman come with `alias vim=vi` in ~/.bashrc? I would very much welcome it as I am used to type vim everywhere but if vi starts instead I am happy too. I know that the solution is to create a customized container but often I want to try something on vanilla containers from the whole range. Didn't want to write about this first but maybe there are more people with the same problem. clime

9 24

Fedora 33 System-Wide Change Proposal: ELN Buildroot and Compose V3
by Stephen Gallagher 29 Jan '21

29 Jan '21

I sent out the V2 version of the Change on Friday and then promptly managed to injure myself and be away from email until today. I've read through the email threads again this morning and I decided that, rather than try to address them one by one, I'd try again with a V3 that hopefully answers some of the repeated questions and concerns on that list. Please see the newly-updated https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose for more details[1]. [1] https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Com…

19 62

In which order does ELN build packages, what build root is it using?
by Mark Wielaard 26 Jan '21

26 Jan '21

Hi, I couldn't build elfutils because of an annobin bug that showed up on ppc64le. Nick was nice enough to fix it and push a new annobin version: https://bodhi.fedoraproject.org/updates/FEDORA-2020-c78fce452e So I could build elfutils again: https://bodhi.fedoraproject.org/updates/FEDORA-2020-06dafb46c1 But now I am getting notices about the ELN build failures: https://koji.fedoraproject.org/koji/buildinfo?buildID=1613859 Which is clearly because it doesn't have the new annobin package. Is this something to worry about? Will ELN resync and re-try the build automatically? Or do I somehow need to take action to get ELN buildroot synced with fedora/rawhide again? Thanks, Mark

5 7

Server Side Public License (SSPL) v1
by Tom Callaway 21 Jan '21

21 Jan '21

After review, Fedora has determined that the Server Side Public License v1 (SSPL) is not a Free Software License. It is the belief of Fedora that the SSPL is intentionally crafted to be aggressively discriminatory towards a specific class of users. Additionally, it seems clear that the intent of the license author is to cause Fear, Uncertainty, and Doubt towards commercial users of software under that license. To consider the SSPL to be "Free" or "Open Source" causes that shadow to be cast across all other licenses in the FOSS ecosystem, even though none of them carry that risk. It is also worth nothing that while there is a draft for a "v2" of the SSPL: A) It is not final. B) It is not in use anywhere at this time (as far as we know). C) The intent of the v2 draft text is not changed from the v1 license currently in use. We have updated our "Bad License" list to include SSPLv1. No software under that license may be included in Fedora (including EPEL and COPRs). Thanks, Tom Callaway Fedora Legal

4 6

Re: NeuroFedora review swaps
by Ankur Sinha 12 Jan '21

12 Jan '21

On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote: > > > I'd like to get this package reviewed please: > > > > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913# > > > > Would anyone like to swap reviews? > > I would review it for wdune sponsoring. Sorry---I'm not current with the wdune scenario. I assumed you meant that you'd review it unofficially as part of the work to get sponsored to the packagers group: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group… I'm not a sponsor yet so I cannot sponsor you to the group myself, but once you've done a few reviews, a sponsor will be happy to take a look at them and guide you through the sponsorship process. If you've submitted a review ticket for wdune already, I will be happy to review it and provide comments. -- Thanks, Regards, Ankur Sinha https://ankursinha.in Time zone: Europe/London

6 27

F34 Change proposal: Wayland by Default for KDE Plasma Desktop (System-Wide Change)
by Ben Cotton 31 Dec '20

31 Dec '20

https://fedoraproject.org/wiki/Changes/WaylandByDefaultForPlasma == Summary == Change the default session selection in SDDM to prefer the Wayland-based KDE Plasma Desktop session over the X11-based one. == Owner == * Name: [[User:Ngompa|Neal Gompa]], [[User:Rdieter|Rex Dieter]], [[User:Jgrulich|Jan Grulich]] * Email: ngompa13(a)gmail.com, rdieter(a)gmail.com, jgrulich(a)redhat.com * Product: KDE Spin * Responsible WG: KDE SIG == Detailed Description == With KDE Plasma 5.20, the KDE Plasma desktop environment has reached a point where nearly all commonly used features in the desktop and all major applications function in the Plasma Wayland environment on all major GPUs (including NVIDIA with the proprietary driver). Starting with Plasma 5.20 in Fedora 34, we will change the default configuration for Wayland and X11 Plasma sessions so that Wayland is preferred and used by default, while permitting the X11 session to be selected as the alternative desktop environment option. == Feedback == ==== Is Wayland ready? ==== Wayland has been used by default for Fedora Workstation (which uses GNOME) since Fedora 25. And while it was somewhat immature initially, today it is a very rock-solid experience on virtually everything Fedora Workstation runs on. The change in Fedora 25 kickstarted the drive to get everything working on Wayland, and the Workstation team succeeded beyond their wildest dreams. Firefox has been Wayland-native by default since Fedora 31 as well. On the KDE side, serious work into supporting Wayland started shortly after GNOME switched to Wayland by default. Unlike GNOME, KDE has a much broader stack in its toolkit, and it has taken longer to get to a usable state. With the Plasma 5.20 release, the Wayland protocol for screencasting as well as middle-click paste finally are supported, completing the required feature set for switching to Wayland by default. ==== What about NVIDIA? ==== Plasma, in fact, ''does'' support NVIDIA GPUs with the proprietary driver on Wayland. It needs to be manually activated, which will be taken care of by the <code>kwin-wayland-nvidia</code> package. So the expectation is that all major GPUs will work just fine. ==== Why not keep using X11? ==== The fact of the matter is, Xorg is in [https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation… "hard maintenance mode"] per [[User:Uraeus|Christian Schaller]] and development on it has basically stopped beyond the most critical of fixes. Combined with the rapid maturation of the Wayland session in KDE Plasma, this is the best time to make the switch and push things over the edge for the KDE ecosystem in the same way that Fedora Workstation did for the GNOME ecosystem. == Benefit to Fedora == Fedora has long been a leader in advancing the adoption of the Wayland protocol as part of the overall strategy to improve the Linux graphical software stack. Much of the quality of Wayland for GNOME can be attributed to the work done by the Fedora Workstation WG as part of advancing the GNOME platform. It is now the KDE SIG's turn to do the same for the KDE platform. By making this change, we are helping push the adoption forward for newer, more streamlined, and overall more actively developed graphics technology for the KDE ecosystem. == Scope == * Proposal owners: ** Modify {{package|kwin}} to switch to Wayland *** Split out <code>/usr/bin/kwin_x11</code> to the <code>kwin-x11</code> subpackage. *** Make {{package|kwin}} require <code>kwin-wayland</code> and recommend <code>kwin-x11</code> *** Add <code>kwin-wayland-nvidia</code> subpackage which contains <code>/usr/lib/environment.d/10-kwin-wayland-nvidia.conf</code> to set <code>$KWIN_DRM_USE_EGL_STREAMS</code> to <code>1</code>. This package will have have a Supplements dependency <code>(kwin-wayland and kmod-nvidia)</code>. ** Modify {{package|plasma-workspace}} to switch to Wayland *** Rename <code>/usr/share/xsessions/plasma.desktop</code> to <code>/usr/share/xsessions/plasma-xorg.desktop</code>, subpackage it out as <code>plasma-workspace-xorg</code>, and have it require <code>kwin-x11</code> *** Rename <code>/usr/share/wayland-sessions/plasmawayland.desktop</code> to <code>/usr/share/wayland-sessions/plasma.desktop</code> *** Make {{package|plasma-workspace}} require <code>plasma-workspace-wayland</code> and recommend <code>plasma-workspace-xorg</code> ** Modify <code>@kde-desktop</code> comps group for Fedora 34 to include <code>plasma-workspace-xorg</code> for the media. * Other developers: N/A (not applicable for this Change) * Release engineering: [https://pagure.io/releng/issue/9741 #9741] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A (not applicable for this Change) == Upgrade/compatibility impact == Systems using certain (very old) graphics hardware or graphics drivers (matrox, etc.) may have problems running the Wayland session. In these (rare) cases, users may have to configure SDDM to use X11. == How To Test == Log into a KDE Plasma desktop. Do any activity you would normally do in your daily desktop use: launching applications, configuring displays, etc. Things should work the same way under Wayland as they used to under X. == User Experience == The user experience should not change noticeably. == Dependencies == This mainly affects the {{package|plasma-workspace}} and {{package|kwin}} packages, and details for the changes for those packages are described in the Scope section. == Contingency Plan == * Contingency mechanism: Revert the file renames and switch <code>plasma-workspace-xorg</code> to be the required package instead of <code>plasma-workspace-wayland</code> * Contingency deadline: beta freeze * Blocks release? Yes * Blocks product? KDE Spin == Documentation == Some upstream documents about Wayland * https://community.kde.org/Plasma/Wayland * https://community.kde.org/KWin/Wayland There is currently no coherent up to date documentation about Plasma Wayland. == Release Notes == The KDE Plasma Desktop is using the Wayland display system now. X applications will continue to run transparently through XWayland. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

25 47

Release rpkg-1.61 and fedpkg-1.39
by Ondrej Nosek 16 Dec '20

16 Dec '20

Hi all, a new version rpkg-1.61 together with fedpkg-1.39 are released containing both features and bugfixes. Some bugfixes were released earlier as patches. Currently, Fedora 32, epel7, epel8 and rawhide packages are in the testing repository, feel free to try these waiting distributions in Bodhi. I will update Fedora 33 and Fedora 31 packages later today because previous updates are going to stable very soon and I do not want to obsolete them now. Version for epel6 won't be released. Changelog (web documentation): https://docs.pagure.org/rpkg/releases/1.61.html https://docs.pagure.org/fedpkg/releases/1.39.html Updates: https://bodhi.fedoraproject.org/updates/?builds=rpkg-1.61-1.el8&builds=rpkg… Alternative link: https://bodhi.fedoraproject.org/updates/?packages=rpkg&page=1 rpkg is also available from PyPI. Thanks to all contributors. Regards

1 1

%lua_requires behaves differently in F33+
by Michel Alexandre Salim 08 Dec '20

08 Dec '20

Hi, Björn added some useful Lua packaging macros in https://bugzilla.redhat.com/show_bug.cgi?id=1447324 One of them, %lua_requires, adds a dependency on either `lua(abi) = %{lua_version}` or, on EL6 and below, on lua >= current version and lua < next version. Somehow this seems to be automatically applied on Fedora 33 and above -- without adding any manual require on lua(abi) e.g. lua-lunitx on Fedora 33 https://bodhi.fedoraproject.org/updates/FEDORA-2020-7c23dc64c0 on Fedora 32, though, the macro is not automatically invoked (so the update below is bad and I need to redo it) https://bodhi.fedoraproject.org/updates/FEDORA-2020-9074133de4 In fact, trying to use %lua_requires does not seem to work, with and without curly braces: error: line 15: Unknown tag: %lua_requires error: line 15: Unknown tag: %{lua_requires} Could someone help explain these two behaviors? I'm working on resuming the Lua packaging draft so I want to have a canonical example on how the macros are supposed to be used. PS Björn -- we should consider moving the macros out of lua-devel and into lua-rpm-macros, that lua-devel then depends on. That will fix the inability to get these macros out to EPEL6 and EPEL7 - on those, lua packages can just BR the macro package directly. -- Michel Alexandre Salim profile: https://keyoxide.org/michel@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2

3 10

Disabling Fedora 30 chroots in Copr
by Jakub Kadlcik 23 Nov '20

23 Nov '20

Hello, we have just disabled Fedora 30 chroots in Copr. According to the Fedora wiki [1], Fedora 30 reached the end of its life on 2020-05-26 and therefore we are disabling it in Copr. That effectively means that from this moment, it is no longer possible to submit builds for the following chroots: - fedora-30-x86_64 - fedora-30-i386 - fedora-30-ppc64le - fedora-30-aarch64 - fedora-30-armhfp [1] https://fedoraproject.org/wiki/End_of_life Jakub

4 12

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel October 2020