devel May 2020

devel@lists.fedoraproject.org

246 participants
396 discussions

Fedora 33 System-Wide Change proposal: systemd-resolved
by Ben Cotton 07 Oct '20

07 Oct '20

https://fedoraproject.org/wiki/Changes/systemd-resolved == Summary == Enable systemd-resolved by default. glibc will perform name resolution using nss-resolve rather than nss-dns. == Owner == * Name: [[User:catanzaro| Michael Catanzaro]] * Email: <mcatanzaro(a)redhat.com> == Detailed Description == We will enable systemd-resolved by default. # We will change the [https://src.fedoraproject.org/rpms/fedora-release/blob/f4cc5b6ce095bb4233e5… fedora-release presets] to enable systemd-resolved instead of disable it. # systemd-libs currently has [https://src.fedoraproject.org/rpms/systemd/blob/bb79fb73875f8e71841a1ee8ede… a %post scriplet] to enable nss-myhostname and nss-systemd by either (a) modifying authselect's user-nsswitch.conf template, if authselect is in use, or (b) directly modifying /etc/nsswitch.conf otherwise. We will work with the systemd maintainers to enable nss-resolve here as well. # We will work with the authselect maintainers to update authselect's minimal and nis profiles to enforce nss-resolve. These profiles modify the hosts line of /etc/resolv.conf. (By default, Fedora uses authselect's sssd profile, which does not modify the hosts line and therefore does not have this problem.) # We will remove our downstream patch to systemd that prevents systemd from symlinking /etc/resolv.conf to /run/systemd/resolve/stub-resolv.conf on new installs. For system upgrades, a systemd-libs %post scriptlet will be used to reassign the symlink during upgrade. Upon detecting this symlink, NetworkManager will automatically enable its systemd-resolved support and configure split DNS as appropriate. systemd-resolved has been enabled by default in Ubuntu since Ubuntu 16.10, but please note we are doing this differently than Ubuntu has. Ubuntu does not use nss-resolve. Instead, Ubuntu uses the traditional nss-dns provided by glibc upstream, so glibc on Ubuntu continues to read /etc/resolv.conf, as is traditional. This extra step is not useful and not recommended by upstream. We want to follow upstream recommendations in using nss-resolve instead. If you do not wish to use systemd-resolved, then manual intervention will be required to disable it: * Modify /etc/authselect/user-nsswitch.conf and remove `resolve [!UNAVAIL=return]` from the hosts line. Run `authselect apply-changes`. (If you have disabled authselect, then edit /etc/nsswitch.conf directly.) * Disable and stop systemd-resolved.service. * Restart the NetworkManager service. NetworkManager will then create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you may create your own /etc/resolv.conf.) == Benefit to Fedora == === Standardization === Fedora will continue its history of enabling new systemd-provided services whenever it makes sense to do so. Standardizing on upstream systemd services is beneficial to the broader Linux ecosystem in addition to Fedora, since standardizing reduces behavior differences between different Linux distributions. Sadly, Fedora is no longer leading in this area. Ubuntu has enabled systemd-resolved by default since Ubuntu 16.10, so by the time Fedora 33 is released, we will be three years behind Ubuntu here. === resolvectl === `resolvectl` has several useful functions (e.g. `resolvectl status` or `resolvectl query`) that will be enabled out-of-the-box. === Caching === systemd-resolved caches DNS queries for a short while. This can [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/682#note_441846 dramatically] improve performance for applications that do not already manually cache their own DNS results. (Generally, only web browsers bother with manually caching DNS results.) === Split DNS === When systemd-resolved is enabled, users who use multiple VPNs at the same time will notice that DNS requests are now sent to the correct DNS server by default. Previously, this scenario would result in embarrassing "DNS leaks" and, depending on the order that the VPN connections were established, possible failure to resolve private resources. These scenarios will now work properly. For example, consider the scenario of Distrustful Denise, who (quite reasonably) does not trust her ISP. Denise uses a public VPN service, public-vpn.example.com, to hide her internet activity from her ISP, but she also needs to use her employer's corporate VPN, corporation.example.com, in order to access internal company resources while working from home. Using the Network panel in System Settings, Denise has configured her employer's VPN to "use this connection only for resources on its network." Distrustful Denise expects that her employer's VPN will receive all traffic for corporation.example.com, and no other traffic. And while this mostly works in Fedora 32, she discovers that it does not work properly for DNS: * If Denise connects to public-vpn.example.com first and corporation.example.com second, she is unable to access internal company resources. All DNS requests are sent to public-vpn.example.com's DNS server, so she is unable to resolve names for internal company websites. * If Denise connects to corporation.example.com first and public-vpn.example.com second, then she is able to access internal company resources. However, it only works because ''all'' her DNS requests are sent to corporation.example.com's DNS server. Sadly for Distrustful Denise, her employer discovers that she has been making some embarrassing DNS requests that she had expected to go through public-vpn.example.com instead. Whichever VPN Denise connects to first receives all DNS requests because glibc's nss-dns module is not smart enough to split the requests. /etc/resolv.conf is just a list of DNS servers to try in order, and NetworkManager has no plausible way to decide which to list first, because both ways are broken, so it just prefers whichever was connected first. And if one server fails to respond, then the next server in the list will be tried, likely resulting in a DNS leak. In contrast, when systemd-resolved is enabled, it will send each DNS request only to the correct DNS server. The DNS server that will be used for each tun interface can be inspected using the resolvectl tool. Migrating away from /etc/resolv.conf will also avoid an annoying footgun with this legacy file: only the first three listed nameservers are respected. All further nameservers are silently ignored. NetworkManager adds a warning comment when writing more than three nameservers to this file, but it cannot do any better than that. === DNS over TLS === systemd-resolved supports DNS over TLS (different from DNS over HTTPS). Although this feature will not initially be enabled by default, using systemd-resolved will enable us to turn on DNS over TLS in a future Fedora release, providing improved security if the user's DNS server supports DNS over TLS. == Scope == * Proposal owners: We will update Fedora presets to enable systemd-resolved by default. * Other developers: This change requires coordination with the systemd and authselect maintainers. * Release engineering: [https://pagure.io/releng/issue/9367 #9367] * Policies and guidelines: none required * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == systemd-resolved will be enabled automatically when upgrading to Fedora 33. After upgrade, /etc/resolv.conf will be managed by systemd and symlinked to /run/systemd/resolve/stub-resolv.conf. '''glibc will no longer look at /etc/resolv.conf when performing name resolution.''' Instead, glibc will communicate directly with systemd-resolved via nss-resolve. systemd adds a large warning comment to the top of /etc/resolv.conf to warn system administrators that changes to this file will be ignored; however, scripts that edit this file manually will break. Because this file is usually managed by NetworkManager, impact to Fedora users will be limited to users who have manually disabled NetworkManager; such users are expected to be experienced system administrators who should be comfortable adapting to the change (or disabling systemd-resolved). Any applications that bypass glibc and read /etc/resolv.conf directly will still work because /etc/resolv.conf will point to systemd-resolved's stub resolver running on 127.0.0.53. Nevertheless, /etc/resolv.conf is provided only for compatibility purposes, and applications should prefer to use either glibc or the systemd-resolved D-Bus API instead; see systemd-resolved(8) for details. In short, '''applications that read /etc/resolv.conf will continue to work as before.''' Applications that write to it will no longer work as expected, but this only previously worked if NetworkManager is disabled, a non-default configuration. It remains possible to disable systemd-resolved if desired. Otherwise, any custom system administration scripts that manage /etc/resolv.conf will need to be updated. === DNSSEC === systemd-resolved's DNSSEC support is known to cause compatibility problems with certain network access points. Per recommendation from the systemd developers, we will change the default value of this setting in Fedora from the upstream default `DNSSEC=allow-downgrade` to `DNSSEC=no` by building systemd with the build option `-Ddefault-dnssec=no`. The upstream default attempts to use DNSSEC if it is working, but automatically disable it otherwise, allowing man-in-the-middle attackers to disable DNSSEC. Sadly, even the allow-downgrade setting suffers known compatibility problems. Because Fedora is not prepared to handle an influx of DNSSEC-related bug reports, we will disable this feature altogether. We anticipate that enabling DNSSEC by default will not be possible in the foreseeable future, or perhaps ever. Instead, enabling DNS over TLS (when supported by the DNS server) seems likely in the near future. === Multicast DNS === systemd-resolved's multicast DNS support conflicts with Avahi. Per recommendation from the systemd developers, we will change the default value of this setting in Fedora from the upstream default `MulticastDNS=yes` to `MulticastDNS=resolve`. Multicast DNS resolving will be enabled, but responding will be disabled. This will require adding a new systemd build option to control the default value of the MulticastDNS setting, similar to the existing `default-dnssec` and `default-dns-over-tls` build options. == How To Test == Load any website in a web browser. If you succeed, then name resolution probably works. Try using `resolvectl status` and, for example, `resolvectl query fedoraproject.org`, to see how they work and sanity-check their output. Users who use multiple VPNs at the same time are encouraged to test DNS in a multiple VPN scenario, to ensure that DNS requests are sent to the expected DNS server. == User Experience == See the Benefit to Fedora section, above, for direct benefits to users who use multiple VPNs at the same time. Users will be able to use the resolvectl tool and the functionality it provides. /etc/resolv.conf will now be managed by systemd rather than by NetworkManager. As before, this file must not be modified directly when it is managed. == Dependencies == In Fedora, /etc/nsswitch.conf is managed by authselect. By default, authselect uses the sssd profile to generate configuration compatible with sssd. In this mode of operation, it does not modify the hosts line in /etc/nsswitch.conf. This is also true if using the winbind profile instead of the sssd profile. However, authselect's minimal and nis profiles do modify the hosts line. These authselect profiles must be updated to enable nss-resolved. If you are using authselect in one of these modes, it will not be possible to cleanly disable systemd-resolved because the hosts line in /etc/nsswitch.conf will be clobbered whenever 'authselect apply-changes' is run. If you wish to disable systemd-resolved and you are using authselect in one of these modes, then you should stop using authselect. This is not expected to cause many problems because virtually all Fedora users will be using the default sssd profile. We do not need to directly make any changes to the /etc/nsswitch.conf shipped by glibc. Changes will be applied in the systemd-libs %post scriptlet. == Contingency Plan == The contingency plan, in the unlikely event of unexpected problems, is simply to revert any changes and not enable systemd-resolved. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == * systemd-resolved is documented in several manpages: resolvectl(1), resolved.conf(5), nss-resolve(8), systemd-resolved(8). * [https://wiki.archlinux.org/index.php/Systemd-resolved Arch Wiki documentation] * [https://wiki.gnome.org/Projects/NetworkManager/DNS NetworkManager DNS documentation] == Release Notes == systemd-resolved is now enabled by default. systemd-resolved provides a system-level DNS cache that can substantially improve performance for applications that do not cache their own DNS results, allows correct handling of split DNS scenarios such as when multiple VPNs are in use, and will allow Fedora to enable DNS over TLS in the future. /etc/resolv.conf will now be managed by systemd-resolved rather than by NetworkManager. /etc/resolv.conf will no longer be read when performing name resolution using glibc; however, it is still provided for compatibility with applications that manually read this file to perform name resolution. Writing to /etc/resolv.conf will no longer work as expected. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

58 388

Fedora 32 system-wide change proposal: reduce installation media size by improving the compression ratio of SquashFS filesystem
by Bohdan Khomutskyi 13 Aug '20

13 Aug '20

Summary Improve compression ratio of SquashFS filesystem on the installation media. Owner Name: Bohdan Khomutskyi Email: bkhomuts(a)redhat.com Current status Targeted release: I propose this change for Fedora 32 Last updated: Jan 5 2020 Pagure.io issue: https://pagure.io/releng/issue/9127 I was unable to create an article in Fedora wiki system. Detailed Description As of Fedora 31, the LiveOS/squashfs.img file on the installation image, is compressed with default settings of mksquashfs. The standard configuration is set to XZ algorithm with block size of 128k and BCJ filter enabled. Those parameters can be adjusted which will lead to a better compression ratio and/or reduction of the CPU usage at build time. This is simple to achieve. Recently, Lorax has gotten support[1] for adjusting the compression options for mksquashfs via the configuration file. The file should be altered as following: [compression] bcj = yes args = -b 1M -Xdict-size 1M -no-recovery Where -b 1M and -Xdict-size 1M are block and dictionary sizes respectively. Could be adjusted. Benefit to Fedora - Reduction of the installation media size and the cost of storing and distributing Fedora. - Reduction of the CPU usage at build time. Depending on which compression parameters chosen. - See a graphical detail at https://pagure.io/releng/issue/9127. Scope - Proposal owners: The build environment should have support for adjusting the Lorax configuration file.. Lorax is a program that produces the LiveOS/squashfs.img file on the installation media. One of the way to allow for such customization, is to add a feature in Pungi, to allow for passing -c option to Lorax. - Release engineering: #9127 <https://pagure.io/releng/issue/9127> - Policies and guidelines: N/A - Trademark approval: N/A Upgrade/compatibility impact - This change comes at a cost of higher memory usage during the installation. Based on my personal estimations, this should not be the issue. Since the decompression should require up to 1MiB per thread. User Experience - Increasing the block size on the current configuration with EXT4 file system, should increase latency while accessing the EXT4 filesystem. The exact impact is to be evaluated. - The impact of latency will be reduced, if the plain SquashFS option is be choosen. Dependencies - N/A Contingency Plan - N/A Documentation https://pagure.io/releng/issue/9127. mksquashfs(1) Release notes See also https://pagure.io/releng/issue/8646 -- Bohdan Khomutskyi Release Configuration Management engineer Red Hat

18 50

Fedora 32 System-Wide Change proposal (late): Enable EarlyOOM
by Ben Cotton 05 Aug '20

05 Aug '20

https://fedoraproject.org/wiki/Changes/EnableEarlyoom == Summary == Install earlyoom package, and enable it by default. This will cause the kernel oomkiller to trigger sooner, but will not affect which process it chooses to kill off. The idea is to recover from out of memory situations sooner, rather than the typical complete system hang in which the user has no other choice but to force power off. == Owner == * Name: [[User:chrismurphy| Chris Murphy]] * Email: bugzilla(a)colorremedies.com == Detailed Description == Workstation working group has discussed "better interactivity in low-memory situations" for some months. In certain use cases, typically compiling, if all RAM and swap are completely consumed, system responsiveness becomes so abysmal that a reasonable user can consider the system "lost", and resorts to forcing a power off. This is objective a very bad UX. The broad discussion of this problem, and some ideas for near term and long term solutions, is located here: Recent long discussions on "Better interactivity in low-memory situations" https://pagure.io/fedora-workstation/issue/98 https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Fedora editions and spins, have the in-kernel OOM (out-of-memory) manager enabled. The manager's concern is keeping the kernel itself functioning. It has no concern about user space function or interactivity. This proposed change attempts to improve the user experience, in the short term, by triggering the in-kernel process killing mechanism, sooner. Instead of the system becoming completely unresponsive for tens of minutes, hours or days, the expectation is an offending process (determined by oom_score, same as now) will be killed off within seconds or a few minutes. This is an incremental improvement in user experience, but admittedly still suboptimal. There is additional work on-going to improve the user experience further. Workstation working group discussion specific to enabling earlyoom by default https://pagure.io/fedora-workstation/issue/119 Other in-progress solutions: https://gitlab.freedesktop.org/hadess/low-memory-monitor Background information on this complicated problem: https://www.kernel.org/doc/gorman/html/understand/understand016.html https://lwn.net/Articles/317814/ == Benefit to Fedora == There are two major benefits to Fedora: * improved user experience by more quickly regaining control over one's system, rather than having to force power off in low-memory situations where there's aggressive swapping. Once a system becomes unresponsive, it's completely reasonable for the user to assume the system is lost, but that includes high potential for data loss. * reducing forced poweroff as the main work around will increase data collection, improving understanding of low memory situations and how to handle them better == Scope == * Proposal owners: a. Modify {{code|https://pagure.io/fedora-comps/blob/master/f/comps-f32.xml.in}} to include earlyoom package for Workstation. b. Modify {{code|https://src.fedoraproject.org/rpms/fedora-release/blob/master/f/80-workstation.preset}} to include: <pre> # enable earlyoom by default on workstation enable earlyoom.service </pre> * Other developers: Restricted to Workstation edition, unless other editions/spins want to opt-in. * Release engineering: [https://pagure.io/releng/issues #9141] (a check of an impact with Release Engineering is needed)  * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == earlyoom.service will be enabled on upgrade. An upgraded system should exhibit the same behaviors as a clean installed system. == How To Test == * Fedora 30/31 users can test today, any edition or spin: {{code|sudo dnf install earlyoom}} {{code|sudo systemctl enable --now earlyoom}} And then attempt to cause an out of memory situation. Examples: {{code|tail /dev/zero}} {{code|https://lkml.org/lkml/2019/8/4/15}} * Fedora Workstation 32 (and Rawhide) users will see this service is already enabled. It can be toggled with {{code|sudo systemctl start/stop earlyoom}} where start means earlyoom is running, and stop means earlyoom is not running. == User Experience == The most egregious instances this change is trying to mitigate: a. RAM is completely used b. Swap is completely used c. System becomes unresponsive to the user as swap thrashing has ensued --> earlyoom disabled, the user often gives up and forces power off (in my own testing this condition lasts >30 minutes with no kernel triggered oom killer and no recovery) --> earlyoom enabled, the system likely still becomes unresponsive but oom killer is triggered in much less time (seconds or a few minutes, in my testing, after less than 10% RAM and 10% swap is remaining) earlyoom starts sending SIGTERM once both memory and swap are below their respective PERCENT setting, default 10%. It sends SIGKILL once both are below their respective KILL_PERCENT setting, default 5%. The package includes configuration file /etc/default/earlyoom which sets option {{code|-r 60}} causing a memory report to be entered into the journal every minute. == Dependencies == earlyoom package has no dependencies == Contingency Plan == * Contingency mechanism: Owner will revert all changes * Contingency deadline: Final freeze * Blocks release? No * Blocks product? No == Documentation == {{code|man earlyoom}} https://www.kernel.org/doc/gorman/html/understand/understand016.html == Release Notes == Earlyoom service is enabled by default, which will cause kernel oom-killer to trigger sooner. To revert to previous behavior: {{code|sudo systemctl disable earlyoom.service}} And to customize see {{code|man earlyoom}}. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

27 118

Headsup: dbus 1.12.10-1.fc29 is missing systemd dbus.service file, breaking almost everything
by Hans de Goede 04 Aug '20

04 Aug '20

Hi All, Just a quick headsup for users following Fedora 29, the dbus 1.12.10-1.fc29 build is missing the systemd dbus.service file, breaking almost everything. Instead it contains a dbus-daemon.service file, but the dbus.socket file expects a matching dbus.service, not dbus-daemon.service. So either hold of on applying updates until this is fixed or exclude dbus. Regards, Hans

17 28

Ditch RPM in favor of DPKG
by Dridi Boukelmoune 19 Jul '20

19 Jul '20

Greetings packagers, I know how important RPM is to the Fedora Project, but it breaks everything downstream and we'd be better off using DPKG as we should have from day one. I'm calling this initiative fedpkg: Fedora Embraces DPKG. A bit of background here: I build both RPMs and DEBs for $DAYJOB and until recently my workflow was quite painful because I needed extra steps between git checkout and git push that involves a VM, because what we ship as apt is in reality apt-rpm. It finally got enough on my nerves to locally build the things I needed and after a month I have already amortized my efforts with the time I save not having to deal with needless extra hoops. In order to successfully build debs on Fedora I needed 4 packages that I'm now submitting for review: https://bugzilla.redhat.com/show_bug.cgi?id=gnu-config https://bugzilla.redhat.com/show_bug.cgi?id=strip-nondeterminism https://bugzilla.redhat.com/show_bug.cgi?id=sbuild https://bugzilla.redhat.com/show_bug.cgi?id=apt I need more than reviews here. Three of those packages are heavy on Perl code, and I'm not a Perl Monk. I tried to CC perl-sig as per the guidelines [1] (also tried with the mailing list address) but bugzilla replied kindly: CC: perl-sig did not match anything Apt is a mix of C, Perl and C++ code, so I would be reassured if I could have a C++ co-maintainer too. I'm only a C developer so if something goes wrong outside of the C realm that would be helpful. Two of those packages should be runtime dependencies of debhelper. The current apt package should be renamed to apt-rpm, I will look up the procedure for that to happen. I understand that when someone sees they should run "apt-get install foo" somewhere on the web it's helpful for non-savvy users that this JustWorks(tm) [2], but apt-rpm is dead upstream and it shouldn't be advertised as apt. I hope I CC'd everyone that should get this heads up, and hope to find help for the reviews and co-maintainership. The packaging does nothing fancy, there are quirks here and there but overall it was rather easy to put together. And of course I would be happy to help with reviews too in exchange. And thanks again to the mock developers, its design is so much better than either sbuild or pdebuild that I barely have pain points left when it comes to RPM packaging. Thanks, Dridi [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/#_perl_sig [2] I'm not against apt-rpm in the base install for example

17 44

Fedora 33 Self-Contained Change proposal: Drop mod_php
by Ben Cotton 13 Jul '20

13 Jul '20

https://fedoraproject.org/wiki/Changes/drop_mod_php == Summary == mod_php (apache2handler) is an optional httpd module to execute PHP scripts, not used. == Owner == * Name: [[User:Remi| Remi Collet]] * Email: remi at fedoraproject dot org == Detailed Description == By default php-fpm is used for a few versions. mod_php is not supported for threaded modules. mod_php usage also increases security risk, sharing the same process than httpd. Drop mod_php from php build. This will only affect user of httpd in "prefork" mode, which will also use php-fpm. php-fpm is already used but most users of httpd and nginx without any issue. The "php" package will be kept as a metapackage, installing (weak dependencies) most commonly used extension, thus reducing the difference between "yum install php" (flat repository) and "yum module install php" (modular repository). == Benefit to Fedora == Only provide the modern way to execute PHP in a web server. == Scope == PHP rebuild (mod_php build is already conditional) * Other developers: N/A (not a System Wide Change) * Release engineering: N/A * 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 == * install and play with your web applications == User Experience == No change. == Dependencies == None (dependency on "php" is already forbidden by Guidelines) == Contingency Plan == * revert * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change), Yes/No * Blocks product? product == Documentation == -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

15 40

Orphaned 215 packages
by Jamie Nguyen 29 Jun '20

29 Jun '20

Hi, This is a follow up for this post: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Below are the packages I've orphaned. See section [d] of the linked email to see how many times each package is listed as Requires by something else. Most are Node.js packages, some still maintained via the 'nodejs-sig' user, though 'nodejs-sig' can't own packages so I orphaned instead. - compat-libuv010 - CutyCapt - dateformat - expresso - jasmine-node - js-json - js-zlib - marked - mocha - nodejs-abbrev - nodejs-ain2 - nodejs-ansi - nodejs-ansi-styles - nodejs-archy - nodejs-asap - nodejs-asn1 - nodejs-assertplus - nodejs-async - nodejs-aws-sign - nodejs-basic-auth-connect - nodejs-batch - nodejs-better-assert - nodejs-bindings - nodejs-block-stream - nodejs-boom - nodejs-buffer-crc32 - nodejs-buffer-equal - nodejs-bunker - nodejs-burrito - nodejs-bytes - nodejs-callsite - nodejs-chalk - nodejs-character-parser - nodejs-charm - nodejs-child-process-close - nodejs-chmodr - nodejs-chownr - nodejs-cmd-shim - nodejs-combined-stream - nodejs-commander - nodejs-component-emitter - nodejs-config-chain - nodejs-connect-timeout - nodejs-console-dot-log - nodejs-cookie - nodejs-cookiejar - nodejs-cookie-jar - nodejs-cookie-parser - nodejs-cookie-signature - nodejs-couch-login - nodejs-cryptiles - nodejs-css - nodejs-cssom - nodejs-css-parse - nodejs-css-stringify - nodejs-csurf - nodejs-ctype - nodejs-cycle - nodejs-debug - nodejs-defined - nodejs-delayed-stream - nodejs-detective - nodejs-diff - nodejs-dryice - nodejs-editor - nodejs-ejs - nodejs-escodegen - nodejs-estraverse - nodejs-esutils - nodejs-eventemitter2 - nodejs-exit - nodejs-expect-dot-js - nodejs-express-session - nodejs-faye-websocket - nodejs-fileset - nodejs-findup-sync - nodejs-forever-agent - nodejs-form-data - nodejs-formidable - nodejs-fresh - nodejs-fstream - nodejs-fstream-ignore - nodejs-fstream-npm - nodejs-generic-pool - nodejs-getobject - nodejs-github-url-from-git - nodejs-glob - nodejs-grip - nodejs-growl - nodejs-grunt-compare-size - nodejs-grunt-contrib-concat - nodejs-grunt-contrib-internal - nodejs-grunt-contrib-uglify - nodejs-grunt-contrib-watch - nodejs-grunt-git-authors - nodejs-gzip-size - nodejs-has-color - nodejs-hawk - nodejs-hoek - nodejs-hooker - nodejs-http-signature - nodejs-inherits1 - nodejs-ini - nodejs-iso8601 - nodejs-isodate - nodejs-jasmine-reporters - nodejs-joose - nodejs-joosex-namespace-depended - nodejs-joosex-simplerequest - nodejs-jscoverage - nodejs-jsonfile - nodejs-jsonify - nodejs-json-stringify-safe - nodejs-js-yaml - nodejs-jwt-simple - nodejs-keypress - nodejs-lazystream - nodejs-lockfile - nodejs-markdown - nodejs-maxmin - nodejs-methods - nodejs-mime - nodejs-mimeparse - nodejs-minimatch - nodejs-minimist - nodejs-morgan - nodejs-ms - nodejs-muffin - nodejs-multiparty - nodejs-mute-stream - nodejs-nan0 - nodejs-ncp - nodejs-node-int64 - nodejs-node-uuid - nodejs-nopt - nodejs-noptify - nodejs-npmlog - nodejs-npm-user-validate - nodejs-oauth-sign - nodejs-opener - nodejs-optimist - nodejs-opts - nodejs-osenv - nodejs-package - nodejs-paperboy - nodejs-parseurl - nodejs-pause - nodejs-pkginfo - nodejs-pretty-bytes - nodejs-promise - nodejs-promzard - nodejs-proto-list - nodejs-pubcontrol - nodejs-qs - nodejs-range-parser - nodejs-read - nodejs-readdirp - nodejs-read-package-json - nodejs-reduce-component - nodejs-repl - nodejs-require-cs - nodejs-requirejs - nodejs-resolve - nodejs-response-time - odejs-response-time rpms - nodejs-retry - nodejs-rimraf - nodejs-ronn - nodejs-runforcover - nodejs-sax - nodejs-semver - nodejs-serve-index - nodejs-setimmediate - nodejs-sha - nodejs-shelljs - nodejs-showdown - nodejs-sigmund - nodejs-slide - nodejs-source-map - nodejs-stack-trace - nodejs-static-favicon - nodejs-stream-counter - nodejs-strip-ansi - nodejs-superagent - nodejs-supertest - nodejs-tar - nodejs-temp - nodejs-temporary - nodejs-testswarm - nodejs-through - nodejs-tiny-lr-fork - nodejs-transformers - nodejs-traverse - nodejs-tunnel-agent - nodejs-uglify-to-browserify - nodejs-uid-number - nodejs-underscore - nodejs-underscore-dot-string - nodejs-utile - nodejs-vhost - nodejs-walkdir - nodejs-weak-map - nodejs-websocket-driver - nodejs-which - nodejs-wordwrap - nodejs-yamlish - nodejs-zlib-browserify - nodejs-zlibjs - uglify-js1 - web-assets Kind regards, Jamie

8 20

Autoclosure of review requests?
by Ben Cotton 26 Jun '20

26 Jun '20

In the weekly Fedora program update that I publish on communityblog.fedoraproject.org, I have started to include a count of the open package review requests. As of this moment, there are ~1300 open review requests. Some of these were opened in 2006. The usual Bugzilla housekeeping (branching, EOL closure, etc) explicitly excludes review request bugs. Having a large number of open, ancient review requests isn't exactly harmful, but it's not very helpful either. Before I make a proposal to FPC, I thought I'd open a conversation here. What does a reasonable cleanup of review requests look like? My initial thought is to close all review requests that were opened >2 years ago, to be performed at the EOL closure for each release. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

6 10

Default editor for LXQt spin
by Raphael Groner 25 Jun '20

25 Jun '20

Hi, writing to general devel list intentionally. No idea if all members of lxqt-sig list can read here, too and especially @zsun. Is there any sense why @lxqt-sig is member of packaging for featherpad? LXQt SIG decided to have enki in the spin as the default editor. Featherpad is not part of LXQt upstream. @lupinix Could you remove lxqt-sig from the members in pagure? Regards, Raphael

3 2

Fedora 33 Self-Contained Change proposal: No more automagic Python bytecompilation phase 3
by Ben Cotton 24 Jun '20

24 Jun '20

https://fedoraproject.org/wiki/Changes/No_more_automagic_Python_bytecompila… == Summary == See [[Changes/No_more_automagic_Python_bytecompilation]] and [[Changes/No_more_automagic_Python_bytecompilation_phase_2]]. Now, <code>%global _python_bytecompile_extra 1</code> won't be allowed anymore and raises an error with a link to this change. == Owner == * Name: [[User:lbalhar| Lumír Balhar]] * Email: lbalhar(a)redhat.com == Detailed Description == See the [[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed Description of the previous Change Proposal]] and the [[Changes/No_more_automagic_Python_bytecompilation#Detailed_Description|Detailed Description of its phase 2]]. Currently, Fedora rawhide contains ~130 packages with `%global _python_bytecompile_extra 1` in their specfiles but surprisingly only 42 of them actually ship any .pyc files outside the standard location <code>/usr/lib(64)?/python[0-9]\.[0-9]+</code>. That might be caused by either of the following: * there is nothing to byte-compile — the statement is a leftover to be removed * The automagic bytecompilation uses <code>/usr/bin/python</code> by default (for historical reasons) but <code>/usr/bin/python</code> is not present in the buildroot by default. Our plan is to finish the announced removal of this automagic Python bytecompilation, remove it from packages where it's not necessary and fix it with <code>%py_byte_compile</code> for packages where it's needed. The [https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Appendix/#… documentation] already contains the following paragraph: If you have *.py files outside of the /usr/lib(64)?/pythonX.Y/ directories and you require those files to be byte compiled (e.g. it’s an importable Python module) you MUST compile them explicitly using the %py_byte_compile macro. Note that not all Python files are importable Python modules; when in doubt, grep the sources for the appropriate import statement. so no changes have to be made there. === Affected packages === From 2020-05-20. bugzilla calamares ceph chromium cinnamon-screensaver edk2 eog-plugins fish fleet-commander-admin fleet-commander-client freecad gaupol gazebo gdb gedit gedit-latex gedit-plugins git-cola glusterfs gnome-code-assistance gnome-devel-docs grass gtk-doc gtranslator ibus ibus-anthy ibus-hangul ibus-libpinyin ibus-libzhuyin ibus-pinyin ibus-table ibus-typing-booster ibus-uniemoji insight kajongg kdevelop-python klatexformula libpeas libreoffice libsmbios libunity lirc lyx mate-menu mingw-glib2 mirrormanager2 odcs onboard otf2 paraview pcs php-opencloud-openstack pygobject2 pygtk2 python-cherrypy python-flask-silk python-genshi python-pycurl python-reportlab qpid-dispatch rhythmbox sems sigul soundconverter sugar sugar-abacus sugar-browse sugar-calculator sugar-castle sugar-chat sugar-clock sugar-colordeducto sugar-countries sugar-deducto sugar-distance sugar-finance sugar-flip sugar-flipsticks sugar-fototoon sugar-fractionbounce sugar-getiabooks sugar-imageviewer sugar-implode sugar-infoslicer sugar-jukebox sugar-kuku sugar-labyrinth sugar-locosugar sugar-log sugar-maze sugar-measure sugar-memorize sugar-moon sugar-nutrition sugar-paint sugar-physics sugar-pippy sugar-playgo sugar-portfolio sugar-pukllanapac sugar-read sugar-recall sugar-record sugar-ruler sugar-speak sugar-srilanka sugar-starchart sugar-stopwatch sugar-story sugar-terminal sugar-turtleart sugar-typing-turtle sugar-view-slides sugar-visualmatch sugar-words sugar-write sugar-xoeditor sugar-xoirc sugar-yupana synfigstudio system-config-repo system-switch-java system-switch-mail texlive totem transmageddon ufw-kde variety virt-manager vtk xed == Benefit to Fedora == More explicit specfiles when it comes to Python byte compilation. This change also supports the dropping of unversioned <code>%{__python}</code> macro. == Scope == * Proposal owners: Change the brp-python-bytecompile script and macros in redhat-rpm-config package, help with transforming the packages. See https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/87 * Other developers: Maintainers of the mentioned python packages will have to change their packages to use explicit <code>%py_byte_compile</code> * Release engineering: No Release engineering work is needed for this change * Policies and guidelines: nothing to be changed * Trademark approval: not needed == Upgrade/compatibility impact == None expected. == How To Test == Build a package with <code>%global _python_bytecompile_extra 1</code>. The build should fail with an actionable error message. == User Experience == The users of this change are packagers. The new behavior should make byte-compilation more obvious, explicit, and discoverable. Users of Fedora should not feel this (except if this change uncovers a packaging bug). == Contingency Plan == * Contingency mechanism: revert the changes in redhat-rpm-config * Contingency deadline: none (not a System Wide Change) * Blocks release? no (not a System Wide Change) * Blocks product? no == Documentation == The guidelines already contain up-to-date documentation. == Release Notes == This change does not deserve Release Notes, it is not user-facing. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

3 2

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