devel January 2020

devel@lists.fedoraproject.org

233 participants
301 discussions

Fonts packaging policy rewrite proposal
by Nicolas Mailhot 14 Mar '20

14 Mar '20

Hi, A fonts packaging policy rewrite proposal has been pushed to FPC today: https://pagure.io/packaging-committee/pull-request/934 It should be clearer, more opinionated, and take into account: – updates of The OpenType standard – variable fonts – web fonts – upstream depreciation of non OpenType formats: final stages of the Harfbuzz consolidation decided at the 2006 Text Layout summit https://www.freedesktop.org/wiki/TextLayout/ – appstream & fonts – weak dependencies – and probably more I forget here It is based on the new fonts-rpm-macros project for automation: This project builds on tooling enhancements in redhat-rpm-config and rpm itself, done during the past two years for the Forge and Go sets of packaging macros. It started 2 years ago as a fork of fontpackages, which is the core of our current fonts packaging guidelines. It will require putting the fonts-srpm-macros package in the default build root, like is done for other domain-specific packaging macro sets. Major additions: – better documentation (clearer and more complete) – better automation (less packager hassle for better and more complete results) Major removals: – tools and scripts – fixing metadata with ttname Mostly because no one seems willing to maintain those scripts, or port ttname to python 3. https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/ showcases the new policy on 62 real-world source packages, generating 139 installation packages. Some of those are badly delayed updates to Fedora packages, others are brand-new packages ready for Fedora inclusion. They include major font packages such as Stix, DejaVu, Droid, IBM Plex. Existing Fedora packages will continue to build, the old fontpackages macros are grandfathered in fonts-rpm-macros for now. They will be removed in a few years to give packagers time to apply the new guidelines. Regards, -- Nicolas Mailhot

2 6

Let's talk about Fedora in the '20s!
by Matthew Miller 29 Feb '20

29 Feb '20

Hi everyone! Since it's a new year and a new decade [*], it seems like a good time to look forward and talk about what we want the Fedora Project to be in the next five and even ten years. How do we take the awesome foundation we have now and build and grow and make something that continues to thrive and be useful, valuable, and fun? [My thoughts below. Feel free to respond to those, or cut here and start your own!] I see three big themes I think we need to tackle. First, I'd like to see Fedora become more of an "operating system factory". The direction we took with the Fedora Editions has been a success — Fedora's general growth and popularity bears that out. But now it's a good time to re-examine the positioning. The Editions were meant to fit big, broad use-cases defined by (at the time) the Fedora Board and FESCo. Since then, everything's become more complicated, with Atomic and then CoreOS, and IoT, and Silverblue — and we never really found a satisfying way to present the work of our other desktop SIGs. So, I think we should revisit the top-level design for Get Fedora. I'm not a designer and I don't have a particular answer in mind, but I think we should try an approach which showcases all of our different outputs in some way which also makes it easy for new users to find the right solution quickly (and to understand the support options and expecations for their choice). In support of that, I'd like to also have that page steer people into tooling for creating new spins —- and I'd like to see us invest in and rebuild the spin creation processes. (Particularly, I'd like spin releases to be decoupled from the main OS release, and for those to be self-service by their SIGs with minimal rel-eng involvement needed.) Second, we need to figure out how to work with language-native packaging formats and more directly with code that's distributed in git repos rather than as tarball releases. We're not adding meaningful end-user value by manually repackaging these in our own format. We _do_ add value by vetting licenses and insuring availability and consistency, but I think we can find better ways to do that. I think the "source git" project is an interesting step here. These two things are linked. I want application developers to find Fedora a convenient and easy way to get their software to users. Pulling from the Fedora container and flatpak registries should give the same feeling of trust and safety that installing and RPM from our repos does today. We're not going to get either of those things with the system we have now. Our value is unclear to both developers and end users, so we just get left out. If we don't address this, we're ultimately going to be reduced to a barely-differentiated implementation of a base OS that no one really cares about, not the rich software ecosystem we've always aspired to build. Third, we really need to continue to grow the project as more than coding and packaging. Obviously that engineering work is the core of the project (and we should grow that too!), but it doesn't matter what we build if no one can find it or find how to use it. We need to feed and grow our documentation and support communities around the world. Marie (our new FCAIC, in case you missed that!) and I have been talking about this, and we hope to really expand the $150-mini-event Mindshare program in the next year, and hopefully build on that further in the coming ones. Those are my thoughts. What other challenges and opportunities do you see, and what would you like us to focus on? ---- [*] https://www.xkcd.com/2249/ (Also, on a more personal note: I've been SUPER swamped with email. If you sent me something over the holiday break and I didn't answer, it's not you, it's me. If I dropped something important, please send again. I'm declaring email bankrupcy and starting the year fresh.) -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

37 94

Minimize systemd for kdump's initramfs
by Kairui Song 25 Feb '20

25 Feb '20

Hi all, I noticed there is a Fedora minimization project which seems could be a bit related to the thing I'm trying to do, and this could be a generic topic. What I'm trying to do is reduce the initramfs size used for kdump. Kdump loads a crash kernel and kdump initramfs image in a prereseved memory region, which get booted when current kernel crashed and perform crash dump. The prereserved memory is limited, so initramfs shouldn't go too big. Kdump in Fedora use Dracut to create bootable initramfs, just hook the final step to do kdump things instead of switch root. And to reduce the size only the binaries and drivers required to boot and perform kdump on current machine is installed. So long it have been working very well. But problem is Dracut works by reusing binaries and libraries from the currently running system, and many userspace binaries and libraries is keep growing and using more space. So the initramfs is also growing. Some component, like Systemd, have grown by a lot, here is a list of the size of part of binaries along with the binaries they required in F31: .... /root/image/bin/bash 4.8M . /root/image/bin/echo 3.4M . /root/image/bin/kmod 7.5M . /root/image/bin/mkdir 4.5M . /root/image/bin/mount 5.3M . /root/image/bin/sh 4.8M . /root/image/bin/systemctl 20M . /root/image/usr/bin/systemctl 20M . /root/image/usr/bin/systemd-cgls 20M . /root/image/usr/bin/systemd-escape 20M . /root/image/usr/bin/systemd-run 20M . ... There are overlays between the libraries they used so when installed into the initramfs, the total size didn't go too big yet. But we can see the size of systemd binary and libraries it used is much bigger than others. And as a compare, from version 219 to 243, systemd's library dependency increased a lot: (v219 is 5M in total, v243 is 20M in total) Version 243: [root@localhost ~]# systemctl --version systemd 243 (v243.4-1.fc31) +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=unified [root@localhost ~]# ldd /usr/bin/systemctl linux-vdso.so.1 (0x00007ffe739a3000) libc.so.6 => /lib64/libc.so.6 (0x00007fe2bbd63000) libsystemd-shared-243.so => /usr/lib/systemd/libsystemd-shared-243.so (0x00007fe2bba8d000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe2bba73000) /lib64/ld-linux-x86-64.so.2 (0x00007fe2bbf73000) librt.so.1 => /lib64/librt.so.1 (0x00007fe2bba68000) libcap.so.2 => /lib64/libcap.so.2 (0x00007fe2bba61000) libacl.so.1 => /lib64/libacl.so.1 (0x00007fe2bba56000) libcryptsetup.so.12 => /lib64/libcryptsetup.so.12 (0x00007fe2bb9e3000) libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007fe2bb8c5000) libip4tc.so.2 => /lib64/libip4tc.so.2 (0x00007fe2bb8bb000) libkmod.so.2 => /lib64/libkmod.so.2 (0x00007fe2bb8a1000) libmount.so.1 => /lib64/libmount.so.1 (0x00007fe2bb83e000) libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007fe2bb7f1000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fe2bb7c2000) libidn2.so.0 => /lib64/libidn2.so.0 (0x00007fe2bb7a0000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fe2bb777000) liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fe2bb756000) libblkid.so.1 => /lib64/libblkid.so.1 (0x00007fe2bb6ff000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe2bb6dd000) libattr.so.1 => /lib64/libattr.so.1 (0x00007fe2bb6d3000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fe2bb6c9000) libdevmapper.so.1.02 => /lib64/libdevmapper.so.1.02 (0x00007fe2bb66c000) libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fe2bb5d6000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fe2bb2f6000) libargon2.so.1 => /lib64/libargon2.so.1 (0x00007fe2bb2ec000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fe2bb2e3000) libjson-c.so.4 => /lib64/libjson-c.so.4 (0x00007fe2bb2d1000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fe2bb2ae000) libpcap.so.1 => /lib64/libpcap.so.1 (0x00007fe2bb262000) libz.so.1 => /lib64/libz.so.1 (0x00007fe2bb248000) libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fe2bb1ba000) libunistring.so.2 => /lib64/libunistring.so.2 (0x00007fe2bb034000) libudev.so.1 => /lib64/libudev.so.1 (0x00007fe2bb006000) libm.so.6 => /lib64/libm.so.6 (0x00007fe2baec0000) Version 219: [root@localhost test]# systemctl --version systemd 219 +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD +IDN [root@localhost test]# ldd /bin/systemctl linux-vdso.so.1 => (0x00007fffc407f000) librt.so.1 => /lib64/librt.so.1 (0x00007f70255bd000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f7025396000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f7025170000) liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f7024f5b000) libgcrypt.so.11 => /lib64/libgcrypt.so.11 (0x00007f7024cda000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f7024ad5000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f70248bf000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f70246a3000) libc.so.6 => /lib64/libc.so.6 (0x00007f70242d5000) /lib64/ld-linux-x86-64.so.2 (0x00007f7025a72000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f7024073000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f7023e6f000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f7023c6a000) libattr.so.1 => /lib64/libattr.so.1 (0x00007f7023a65000) Kdump in Fedora relies heavily on Dracut, and Dracut relies on systemd. But kdump only expect systemd to start some services. I think there might be many features not needed by kdump being brought in. Is there any way to have a smaller systemd binary that is just enough to boot the initramfs into the stage before switch-root? -- Best Regards, Kairui Song

5 11

epel8: BuildrootError: could not init mock buildroot
by Jiri Kucera 24 Feb '20

24 Feb '20

Hello, when doing `fedpkg scratch-build --target epel8-candidate --srpm sox-14.4.2.0-29.el8.src.rpm`, I get: <snip> [====================================] 100% 00:00:01 1.02 MiB 773.06 KiB/sec Building sox-14.4.2.0-29.el8.src.rpm for epel8-candidate Created task: 41245726 Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=41245726 Watching tasks (this may be safely interrupted)... 41245726 build (epel8-candidate, sox-14.4.2.0-29.el8.src.rpm): free 41245726 build (epel8-candidate, sox-14.4.2.0-29.el8.src.rpm): free -> FAILED: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information 0 free 0 open 0 done 1 failed 41245727 rebuildSRPM (noarch): FAILED: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information 41245726 build (epel8-candidate, sox-14.4.2.0-29.el8.src.rpm) failed </snip> When I investigating the logs (both `root.log` and `mock_output.log`), I found that `dnf` has problem with package downloading: <snip> Downloading Packages: Error: Error downloading packages: Status code: 404 for https://infrastructure.fedoraproject.org/repo/rhel/rhel8/koji/latest/x86_64… (IP: 10.5.126.23) </snip> I get the same result also with `--target epel8`. Any ideas how to resolve this issue? Regards Jiri

5 7

[Retired] gstreamer & gstreamer-plugins-base
by Tom Callaway 20 Feb '20

20 Feb '20

Since I've moved my last dependent package off of this old stack, I've retired gstreamer & gstreamer-plugins-base in rawhide (again). Before reviving these poor and tired packages, please consider the following: * Upstream is not maintaining this code branch anymore. * There are significant improvements in the gstreamer0.10 branch (which is separately packaged and maintained in Fedora) Thanks, Tom

10 24

fedora-gpg-keys not updated yet again
by Zbigniew Jędrzejewski-Szmek 19 Feb '20

19 Feb '20

This seems to repeat every 6 months: rawhide mock is broken on stable Fedora, people are scrambling to install the right gpg keys, dnf reports unsigned packages. Looking at https://bodhi.fedoraproject.org/updates/?packages=fedora-repos, there is still no F30 package with the right keys. Can we *please* send out the FN+1 and FN+2 keys a month before branching, to *all* releases of Fedora, so we can avoid this pointless scramble? Zbyszek

14 27

RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers
by Miro Hrončok 17 Feb '20

17 Feb '20

Hello, Fedora has an approved security policy since September 2018 [0]: > If a CRITICAL or IMPORTANT security issue is currently open > against a package, or a security issue of lower severity has been > open for at least 6 months, four weeks before the branch point a > procedure similar to long-standing FTBFS will be triggered > immediately, with 8 weeks of weekly notifications to maintainers and > subsequent orphaning and then subsequent removal from distribution. > This applies to all packages, not just leaf. I have decided to have a look into this, since this has been approved more than a year ago and nothing ever happened since. Fedora has a very big pile of open CVE bugzillas [2]. There are several things I'd like us to consider based on the experience from the FTBFS policy adjustments [1] before I go implement stuff: A. It's easier to **orphan** packages soon, retire later -- this allows the dependent package owners to notice the breakage and possibly adopt the packages themselves if needed while gives very little room for "cheating". B. Getting this done on a certain point in the release schedule is complicated and requires a lot of planning and focus -- if we miss the window, nothing can change until the next release. We have missed the window 3 times already. C. Also because of the fixed date, the CRITICAL or IMPORTANT security issues have no response time, if you get a new one at a certain point, the package is immediately treated as problematic, while getting it 1 day later, there is a 6 month period where no action is required. I'd like to adjust the policy before I go implement some tooling around this. This is vague proposal of what I think would work easier for both "the executioner" and the affected maintainers: 1. We automatically send reminders to NEW security bugzillas (as with FTBFS) 2. BZs that remain in NEW state for X reminders: pkg is orphaned 3. BZs that remain not CLOSED for Y months: pkg is retired (with notifications) Point 2 makes it so that only a couple remaining packages actually need to survive unfixed to point 3. Hence, point 3 can happen at a certain point in the schedule with less severe impact of points B and C -- and if we miss the window, we still have point 1 happening. The bugzilla reminders are sent every third calendar week (every week is too disturbing). Here is an initial (albeit randomly generated) proposal of X and Y: severity CRITICAL/HIGH MEDIUM LOW X 2 4 6 Y 2 4 6 Note that X=1 effectively means anything from 1 second to 3 weeks, X=2 means anything from 3 weeks (+1 second) to 6 weeks. Hence, we cannot orphan packages after just 1 reminder. I've made it so that X always equals to Y and every lower level is +2, to make it easier to document, understand and remember, however this is not required. For this example a critical/high CVE would get a reminder every third calendar week. After two reminders (that is after 3-6 weeks), if still in NEW state, package is orphaned. The maintainer (and others) still have extra 6 weeks to claim it. If the bug is ASSIGNED, MODIFIED, etc., the package may be retired after 2 months, but that only happens regularly at a certain point in the schedule. Similarly, a package with a medium CVE NEW bugzilla would be orphaned after 4 reminders (after 9-12 weeks), retired at a point if still not CLOSED after 4 months. With low severity, that is 6 reminders (after 15-18 weeks), retired at a point if still not CLOSED after 6 months (similarly to the current policy). Please share your feedback, before I proceed with this to FESCo. If somebody would be interested in maintaining this procedure, I'd be happy to hand over that responsibility to anybody who is willing to help. The idea is to start with semi-automation and have something -- currently we had hoped for fully automated and we have nothing. [0] https://pagure.io/fesco/issue/1935 [1] https://pagure.io/fesco/issue/2244 [2] https://mivehind.net/2020/01/28/Fedora-has-too-many-security-bugs/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

18 42

Git Forge Requirements: Please see the Community Blog
by Leigh Griffin 13 Feb '20

13 Feb '20

Hey Everyone, On behalf of the CPE team I want to draw the communities attention to a recent blog post which you may be impacted by: https://communityblog.fedoraproject.org/git-forge-requirements/ We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community. This mail is being sent to the devel, mindshare and council-discuss lists for maximum visibility on a BCC to allow each list have their own views. Please forward it to any other list you may feel is relevant to maximise the exposure. Thanks in advance, Leigh -- Leigh Griffin Engineering Manager Red Hat Waterford <https://www.redhat.com/> Communications House Cork Road, Waterford City lgriffin(a)redhat.com M: +353877545162 IM: lgriffin @redhatjobs <https://twitter.com/redhatjobs> redhatjobs <https://www.facebook.com/redhatjobs> @redhatjobs <https://instagram.com/redhatjobs> <https://red.ht/sig>

46 147

Co-Maintainers wanted for Pantheon / elementary apps (Vala / GObject / GTK+)
by Fabio Valentini 13 Feb '20

13 Feb '20

Hi everybody, With more responsibilities (FPC, Stewardship SIG, FESCo) and the ever-growing number of packages I maintain, I don't have as much time for the things I originally started my contributions to fedora with - the Pantheon desktop and the accompanying elementary applications. What makes things worse is that I am not particularly proficient with Vala or C/GObject, other than including upstream patches or doing simple backports. That means some issues are punted until upstream projects get around to fixing them (and if these issues are only affecting "third-party" distros like fedora, that can take a while). Also, the fact that GNOME frequently (almost with every new major stable release, which means with almost every fedora release) breaks something - either subtly or not - does not help. gnome-settings-daemon changes its DBus interfaces almost every release. mutter makes sweeping API changes almost every release. Both gala and the elementary LightDM greeter can't keep up with upstream mutter, and are basically still stuck on mutter 3.28 support (which is why there is a mutter328 compat package) ... Overall, this results in the quality of all these packages not being as high as I would like it to be (though it's still pretty good, all things considered). In particular, there are some components that are more "crashy" than the rest, and I don't have the time and skill to get deep into debugging the issue in most cases: - wingpanel (the panel for Pantheon); issues in individual indicators also crash the whole app because they are just dlopen()ed - switchboard (the settings application); issues in individual settings panels also crash the whole app because they are just dlopen()ed - gala (the window manager): obviously bad if the WM crashes, though not as bad because it's still an Xorg session - plank (the dock); also optionally used on XFCE (I think) - sequeler (third-party SQL client developed for Pantheon) I would greatly appreciate if somebody who knows their GObject-fu could help me out here. The elementaryOS upstream developers are usually helpful and accept patches - even for things that are not a problem on elementaryOS, so long as they can be switched on/off with e.g. conditional compilation. But reported issues - that only affect fedora - without attached patches / PRs are obviously low priority for them, and often sit untouched for months or years. In general, I manage to keep the packages for Pantheon / elementary projects up-to-date. Having set up "nightly" builds on COPR a few years ago really helps to catch potential issues early. If anybody is interested, here are some pointers: - all packages are tracked in koschei, in the decathorpe/elementary group: https://koschei.fedoraproject.org/groups/decathorpe/elementary - nightly builds are done on COPR: https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-nightly/ Thanks, Fabio

3 2

Announcing multi-builds updates gating
by Pierre-Yves Chibon 12 Feb '20

12 Feb '20

Good Morning Everyone, We are pleased to announce that the work to gate rawhide packages has leveled up! Back in July we announced the first phase where bodhi got the support to gate single-build updates. We can now officially announce that bodhi can gate multi-builds updates. This is achieved through the use of side-tags, which can be created on demand via ``fedpkg request-side-tag``. The package can then be built using ``fedpkg build --target=<your side-tag>`` or via ``fepdkg chain-build --target=<your side-tag>``. Once all your packages are built, you can create a bodhi update from this side-tag using either the ``Use Side-Tag`` drop-down or in the CLI by using the ``--from-tag`` argument to the ``bodhi updates new`` command. Every build in the update will then be tested by the CI system which will report the outcome. Bodhi will then query greenwave which will rely on the collection of these individual results to make a decision about whether to gate the update or not. More detailed documentation is available at: - https://fedoraproject.org/wiki/Package_update_HOWTO - https://docs.fedoraproject.org/en-US/rawhide-gating/ Note: this is not the end of rawhide-gating. We still have some changes planned to make it easier for greenwave to make a decision about an update containing multiple builds, we want to improve the documentation for on-boarding new CI systems and make them matter for rawhide as well as for stable releases. We then have all the work ahead to improving our tests, including enabling some of them distribution-wide, looking at the reverse dependencies or testing for the impact of an update on our composes. Looking forward for your feedback! Pierre For the rawhide gating team _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…

7 10

← Newer
1
2
3
4
5
6
7
...
31
Older →

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 January 2020