Re: peek package
On 02/01/2020 06:53, Benson Muite wrote: There are a number of screen recording alternatives that are simpler than OBS Studio, including vokoscreen, Kazam, Simplescreenrecorder etc, The main problem is that most depend on FFMPEG. FFMPEG has a license that is compatible with the main Fedora repository (https://ffmpeg.org/legal.html), but is typically built with a number of nonfree dependencies https://github.com/rpmfusion/ffmpeg/blob/master/ffmpeg.spec - CUDA support, libfaac, libnpp, libfdk-aac One could compile a version of FFMPEG without these, but performance on some platforms may drop significantly and some functionality may be missing. Not clear if this would be useful for other projects that depend on FFMPEG as well. Licenses are not the only issue. The big issue with ffmpeg, like with many multimedia related things, is patents. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
Perhaps OP should not sneaky asking for retiring functional package? Maybe he should instead file a bug and ask maintainer first about this and discuss with it? I might have miss this thread and didn't even notice it. TBH all this just demotivating from packaging something at all. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Heads up: Updating Python RPM dependency generators
Hello, this is just a heads up that we are about to update the Python RPM dependency generators to support versions like 1.2.*, the ~= operator etc. See the PR: https://src.fedoraproject.org/rpms/python-rpm-generators/pull-request/4 The code is tested and no backwards incompatible breakage is anticipated (some requirements might end up being a bit different thou). If you get a weird behavior or broken deps because of this, please report here or trough bugzilla. Thanks, -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > 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/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. All systemd binaries will mostly link to the same libraries (because they link to a private shared library, which links to various other shared libraries). So this "20M" will be repeated over and over, but it's the same dependencies. While we'd all prefer for this to be smaller, 20M should is actually not that much... > 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) This is slightly misleading. Code was moved from individual binaries to libsystemd-shared-nnn.so, so if you look at the deps of just a single binary, you'll see many more deps (because libsystemd-shared-nnn.so has more deps). But the total number of deps when summed over all binaries grew much less. A more useful measure would be the size with deps summed over all systemd binaries that are installed into your image in v219 and v243. I don't have a link at hand, but there's work being done to use openssl for all crypto, which would reduce the dependency list nicely. > Is there any way to have a smaller systemd binary that is just enough > to boot the initramfs into the stage before switch-root? We don't have anything like this now, sorry! Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On 1/2/20 11:37 AM, Tom Hughes wrote: On 02/01/2020 06:53, Benson Muite wrote: There are a number of screen recording alternatives that are simpler than OBS Studio, including vokoscreen, Kazam, Simplescreenrecorder etc, The main problem is that most depend on FFMPEG. FFMPEG has a license that is compatible with the main Fedora repository (https://ffmpeg.org/legal.html), but is typically built with a number of nonfree dependencies https://github.com/rpmfusion/ffmpeg/blob/master/ffmpeg.spec - CUDA support, libfaac, libnpp, libfdk-aac One could compile a version of FFMPEG without these, but performance on some platforms may drop significantly and some functionality may be missing. Not clear if this would be useful for other projects that depend on FFMPEG as well. Licenses are not the only issue. The big issue with ffmpeg, like with many multimedia related things, is patents. Thanks for the clarification. FFMPEG seems not to have very many alternative software packages. Royalty free codecs are also being developed, for example AV1 (https://en.wikipedia.org/wiki/AV1), and adoption of these will likely grow. I suspect there would be interest in having a royalty free version of FFMPEG for use by content creators that satisfies Fedora packaging guidlines, though unclear if at present this would be useful for many of the multimedia related packages. This would also likely need some interaction with FFMPEG developers. Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On 1/2/20 12:05 PM, Benson Muite wrote: On 1/2/20 11:37 AM, Tom Hughes wrote: On 02/01/2020 06:53, Benson Muite wrote: There are a number of screen recording alternatives that are simpler than OBS Studio, including vokoscreen, Kazam, Simplescreenrecorder etc, The main problem is that most depend on FFMPEG. FFMPEG has a license that is compatible with the main Fedora repository (https://ffmpeg.org/legal.html), but is typically built with a number of nonfree dependencies https://github.com/rpmfusion/ffmpeg/blob/master/ffmpeg.spec - CUDA support, libfaac, libnpp, libfdk-aac One could compile a version of FFMPEG without these, but performance on some platforms may drop significantly and some functionality may be missing. Not clear if this would be useful for other projects that depend on FFMPEG as well. Licenses are not the only issue. The big issue with ffmpeg, like with many multimedia related things, is patents. Thanks for the clarification. FFMPEG seems not to have very many alternative software packages. Royalty free codecs are also being developed, for example AV1 (https://en.wikipedia.org/wiki/AV1), and adoption of these will likely grow. I suspect there would be interest in having a royalty free version of FFMPEG for use by content creators that satisfies Fedora packaging guidlines, though unclear if at present this would be useful for many of the multimedia related packages. This would also likely need some interaction with FFMPEG developers. Relevant packaging guideline: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Patented_Software Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
Il 02/01/20 09:52, Artem Tim ha scritto: > Perhaps OP should not sneaky asking for retiring functional package? Maybe he > should instead file a bug and ask maintainer first about this and discuss > with it? I might have miss this thread and didn't even notice it. TBH all > this just demotivating from packaging something at all. > ___ In my original post I had CC'ed `peek-maintai...@fedoraproject.org` and I supposed this would have reached you directly. I did not know this isn't working anymore (I later received an unreachable address in reply). So I didn't "sneaky ask" anything. That said, if this is working for Gnome out of the box without external dependencies, I apologize. I've just seen that the project homepage lists ffmpeg as runtime dependency. Indeed, a more descriptive error would be nice (and, maybe, viewable in a window message, not only from CLI). Mattia ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On Thu, 02 Jan 2020 10:02:25 +, Mattia Verga via devel wrote: > In my original post I had CC'ed `peek-maintai...@fedoraproject.org` and > I supposed this would have reached you directly. I did not know this > isn't working anymore (I later received an unreachable address in > reply). So I didn't "sneaky ask" anything. It has _never_ worked before, because it is PACKAGENAME-owner@ instead. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Two stage Ruby compilation / Bootstrapping
> With recent changes, such as [3], I am afraid that the day has come. It seems that the day came on Ruby 2.7.0, right? Ruby 2.7.0 includes the commit [3]. > Thoughts? > On the positive side, 1(2) would allow us to stay better in line with > "Pregenerated code" guidelines [5], because there is already quite a lot > of pre-generated code shipped in Ruby release tarball. For my first impression,, I agree with the way 1) and 2). > 2) Use previous version of Ruby available in Fedora to bootstrap Ruby. > But this does not work ATM, at least when RubyGems are installed. And > upstream is doing what they can to make RubyGems inseparable [4]. If we create the SRPM for "Use previous version of Ruby available in Fedora to bootstrap Ruby", which name do you like? The candidates: * rpms/ruby-bootstrap * rpms/bootstrap-ruby * rpms/previous-ruby -- Jun | He - His - Him ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
No prob. :) But i didn't received any notification so this could be upsetting a little bit if package was retired. Community barely fixed crash dump recently [1] and Fedora users before often write me on email with various questions, so this makes me believe that app is not useless and users interesting in it. And as for Recommends in spec file yes, this my bad and this not allowed but i believed that soon this will be legal [2]. > Indeed, a more descriptive error > would be nice (and, maybe, viewable in a window message, not only from CLI). Adding 'gnome-shell' as hard dependency could be easiest way to fix but i believe we don't want this because this install many gnome packages so let's try move in this direction [3] until we come up with something better. [1] https://github.com/phw/peek/issues/419 [2] https://pagure.io/packaging-committee/issue/914#comment-607823 [3] https://github.com/phw/peek/issues/539 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On 02/01/2020 11:05, Michael Schwendt wrote: On Thu, 02 Jan 2020 10:02:25 +, Mattia Verga via devel wrote: In my original post I had CC'ed `peek-maintai...@fedoraproject.org` and I supposed this would have reached you directly. I did not know this isn't working anymore (I later received an unreachable address in reply). So I didn't "sneaky ask" anything. It has _never_ worked before, because it is PACKAGENAME-owner@ instead. Actually I believe PACKAGENAME-maintainers@ (with an s) is now the preferred form and -owner is regarded as deprecated. The idea being to generally promote the idea of multiple maintainers and discourage the concept of ownership by an individual. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On Thu, Jan 2, 2020, 12:15 Artem Tim wrote: > No prob. :) But i didn't received any notification so this could be > upsetting a little bit if package was retired. Community barely fixed crash > dump recently [1] and Fedora users before often write me on email with > various questions, so this makes me believe that app is not useless and > users interesting in it. > (snip) And as for Recommends in spec file yes, this my bad and this not allowed > but i believed that soon this will be legal [2]. > No, that is definitely not the case. W (the FPC and spot) concluded that specifying *any* requirements (be it hard or weak dependencies) that can only be fulfilled outside the fedora repos is a no-go, especially for patent-encumbered software like ffmpeg. Which is, for example, why the automatic dependency generator for R needed to be adjusted. Fabio > > Indeed, a more descriptive error > > would be nice (and, maybe, viewable in a window message, not only from > CLI). > > Adding 'gnome-shell' as hard dependency could be easiest way to fix but i > believe we don't want this because this install many gnome packages so > let's try move in this direction [3] until we come up with something better. > > [1] https://github.com/phw/peek/issues/419 > [2] https://pagure.io/packaging-committee/issue/914#comment-607823 > [3] https://github.com/phw/peek/issues/539 > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On Thu, 2 Jan 2020 11:24:08 +, Tom Hughes wrote: > Actually I believe PACKAGENAME-maintainers@ (with an s) is now the > preferred form and -owner is regarded as deprecated. Is this documented _anywhere_? The following page still mentions the -owner alias https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb and would be a good place where to mention a switch to something else. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On 02.01.2020 10:05, Benson Muite wrote: > I suspect there would be interest in having a royalty free version of FFMPEG No, please, don't do this. It will be a huge headache for RPM Fusion maintainers. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
Peek is on Flathub btw. On Thu, Jan 2, 2020 at 2:08 PM Vitaly Zaitsev via devel wrote: > > On 02.01.2020 10:05, Benson Muite wrote: > > I suspect there would be interest in having a royalty free version of FFMPEG > > No, please, don't do this. It will be a huge headache for RPM Fusion > maintainers. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.org) > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On 02. 01. 20 13:04, Michael Schwendt wrote: On Thu, 2 Jan 2020 11:24:08 +, Tom Hughes wrote: Actually I believe PACKAGENAME-maintainers@ (with an s) is now the preferred form and -owner is regarded as deprecated. Is this documented _anywhere_? The following page still mentions the -owner alias https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb and would be a good place where to mention a switch to something else. Updating. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
Il 02/01/20 12:05, Michael Schwendt ha scritto: > On Thu, 02 Jan 2020 10:02:25 +, Mattia Verga via devel wrote: > >> In my original post I had CC'ed `peek-maintai...@fedoraproject.org` and >> I supposed this would have reached you directly. I did not know this >> isn't working anymore (I later received an unreachable address in >> reply). So I didn't "sneaky ask" anything. > It has _never_ worked before, because it is PACKAGENAME-owner@ instead. Ah, thanks! I was remembering the wrong format, then. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On 02.01.2020 13:12, Damian Ivanov wrote: > Peek is on Flathub btw. Flathub is a third-party repository with low-quality packages. I'm not going to trust it. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
glusterfs-7.1 update stuck in pending->testing for 10 days
related to bodhi having gone down? Can someone kick it please? Thanks -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: Systemd presets for user units
https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units == Summary == System units are managed through presets [https://fedoraproject.org/wiki/Features/PackagePresets since F18] and by policy, presets are carried by the fedora-release package. This policy is now extended to user units. == Owner == * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: zbyszek at in waw pl == Detailed Description == The preset mechanism for user units was already in place, but we were missing the actual preset files, and the default was "enable *" instead of "disable *" as for system services. Systemd will now provide a /usr/lib/systemd/user-preset/99-default-disable.preset that marks user services as disabled by default. Any user services which should be enabled will be to get an appropriate preset in /usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific file. Most packages already call into the preset mechanism, but those which don't will be adjusted to do that. This is essentially a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good reason to treat user services different than system services in this regard. On the systemd side this change is very simple, but all packages that provide user units need to be reviewed to check if they are enabled after the change if appropriate. == Benefit to Fedora == User and system services are handled in the same way. Local configuration may be used to override which services should be enabled after upgrade. In particular, "local" in this context may mean "per-spin" or "per-user". == Scope == * Proposal owners: ** review all packages that provide user services in Fedora and submit PRs when changes are needed ** add a new presets file to the fedora-release package for user units ** submit a proposal to FPC to update the guidelines (essentially to say "... and the same for user services."). * Other developers: ** FPC: review (and accept ;)) the guidelines changes ** other maintainers: verify that units in their packages are enabled or not as appropriate after package installation * Release engineering: n/a * Policies and guidelines: a pull request will be submitted * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Should not be user visible. Some units which are are currently enabled by mistake will not be enabled anymore on new installations. == How To Test == Install a new system (or uninstall and reinstall some packages). Verify that the appropriate units are enabled for the user session. == User Experience == N/A == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert the changes. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == A pull request for the packaging guidelines will be submitted. == Release Notes == Not needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_transaction == Summary == Scriptlets to restart each service that should be restarted in each rpm package will be replaced by a declaration in the unit file and an rpm transaction trigger that fires at the end and restarts all services. == Owner == * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: zbyszek at in waw pl == Detailed Description == Currently, when packages containing systemd services are upgraded, they are restarted through %post scriptlets in each package. In other words, the scriptlets specify which services should be restarted and actually run the command to restart the service. An alternative mechanism will be provided, whereby the unit file contains a setting which specifies that the service should be restarted on upgrade, and a %transfiletrigger in the systemd package will restart all services marked so in upgraded packages at the end of transaction. To mark a services as "restart on upgrade" the unit file should contain an option to mark it so. This can be either in the main .service file, or e.g. in a drop-in file in /usr/lib/systemd/system/.service.d/needs-restart.conf. The exact name of the option should be something like X-restart-on-upgrade=true|false. I'll take the proposal for discussion in systemd upstream, since this is something that could be used across distributions, and then the "X-" prefix could be dropped and/or the name changed. == Benefit to Fedora == Which services should be restarted is specified declaratively and the number of scriptlets is reduced. Admins may easily override this by providing appropriate drop-ins of their own of higher priority. Services are restarted after the transaction is finished, all libraries have been upgraded, and systemd configuration reloaded. This solves https://bugzilla.redhat.com/show_bug.cgi?id=1614751, but also a more general problem: a service may be restarted before any of its dependencies (files and static content and whatnot) have been upgraded, and while some contents from the old rpm are still on disk. Restarting after all packages have been upgraded avoids this issue. In the future, restarting of services shall also be extended to user managers (i.e. to restart all user services after the packages providing those services have been upgraded). This is not part of this proposal, but moving the information what to restart into systemd units makes this much easier. == Scope == * Proposal owners: ** implement the relevant bits in the systemd package ** submit a proposal to FPC ** convert a subset of packages * Other developers: ** FPC: review (and accept ;)) the guidelines changes ** other maintainers: convert other packages * Release engineering: n/a * Policies and guidelines: a pull request will be submitted * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == This change should be backwards compatible, i.e. unconverted packages can be still installed on new systems, and services will be restarted on upgrade like before. Converted packages may be installed on older systems but will not get restarted on upgrades. == How To Test == This change should be mostly invisible to users. Check that during upgrades services are restarted and that no warnings are emitted. == User Experience == N/A == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert to previous mechanism. This will require a revert of changes to the spec file and a rebuild of the package. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == TBD. == Release Notes == Not needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: GCC10
https://fedoraproject.org/wiki/Changes/GCC10 == Summary == Switch GCC in Fedora 32 to 10.x.y, rebuild all packages with it, or optionally rebuild just some packages with it and rebuild all packages only in Fedora 33. == Owner == * Name: [[User:Jakub|Jakub Jelínek]] * Email: ja...@redhat.com == Detailed Description == GCC 10 is currently in stage3, switching to stage4 in January, at which point it will be in a prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the middle of April. rpms will be built in early January, but Jeff Law has been testing x86_64 Fedora test mass rebuilds with GCC 10 snapshots for a while. == Benefit to Fedora == See http://gcc.gnu.org/gcc-10/changes.html for the list of changes. == Scope == * Proposal owners: Prepare rpms for the new compiler, push them into rawhide, watch voluntary rebuilds, fix bugs as they are reported, watch fallout from mass rebuild. * Other developers: N/A (not a System Wide Change) Adjust for what will be written in https://gcc.gnu.org/gcc-10/porting_to.html , fix bugs in packages that will show up after rebuild or report if there are bugs on the compiler side. * Release engineering: Perform a mass rebuild, which will be needed for the LTO System Wide change too. * Policies and guidelines: N/A (not a System Wide Change) I don't think so, this is a usual system compiler update that is being done every year. I think we have skipped GCC 4.2, so in Fedora this is likely the 15th such System Wide change. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No impact == How To Test == GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc. == User Experience == Users will be able to see compiled code improvements and use the newly added features. Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-10/porting_to.html, or, if they detect a GCC bug, report it. == Dependencies == libtool, annobin, gcc-python-plugin depend on exact gcc version, those need to be rebuilt. == Contingency Plan == If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in 12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past, but worst case we can mass rebuild everything with older gcc again. Jeff Law has performed test mass rebuild on x86_64. * Contingency mechanism: (What to do? Who will do it?) Revert to older gcc, mass rebuild everything again * Contingency deadline: Before release * Blocks release? Yes * Blocks product? No == Documentation == http://gcc.gnu.org/gcc-10/ == Release Notes == Fedora 32 comes with GCC 10.1 as primary compiler, see http://gcc.gnu.org/gcc-10/changes.html for user visible changes in it. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: Golang 1.14
https://fedoraproject.org/wiki/Changes/golang1.14
== Summary ==
Rebase of Golang package to upcoming version 1.14 in Fedora 32,
including rebuild of all dependent packages(pre-release version of Go
will be used for rebuild, if released version will not be available at
the time of the mass rebuild).
== Owner ==
* Name: [[User:Jcajka| Jakub Čajka]]
* Email: jca...@redhat.com
== Detailed Description ==
Rebase of Golang package to upcoming version 1.14 in Fedora 32. Golang
1.14 is schedule to be released in Feb 2020.
Due to current nature and state of Go packages, rebuild of dependent
package will be required to pick up the changes.
== Benefit to Fedora ==
Staying closely behind upstream by providing latest release of golang,
which includes performance improvements and improvements in support
for currently supported platforms among other bug fixes and new
features. For complete list of changes see upstream change notes at
https://tip.golang.org/doc/go1.14 . In result Fedora will be providing
solid development platform for Go language.
== Scope ==
* Proposal owners: Rebase golang package in f32, help with resolving
possible issues found during package rebuilds.
* Other developers: Fix possible issues, with help from golang maintainers.
* Release engineering: Rebuild of dependent packages as part of
planned mass-rebuild. Tracking ticket
https://pagure.io/releng/issue/9136
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
None
== How To Test ==
;0.
:a)Install golang 1.14 from rawhide and use it to build your
application(s)/package(s).
:b)Scratch build against rawhide.
;1.
:Your application/package built using golang 1.14 should work as expected.
== User Experience ==
None
== Dependencies ==
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(golang)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
Omitted due to the number of packages listed ~1100.
Not all of listed require re-build as they might not ship binaries
and/or do not use golang compiler during build, but only use Go rpm
macros that pull it in to every build root.
== Contingency Plan ==
* Contingency mechanism:Reverting to golang version 1.13.X if
significatnt issues are discovered.
* Contingency deadline: Beta Freeze(?)
* Blocks release? No
* Blocks product? No
== Documentation ==
https://tip.golang.org/doc/go1.14
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: Move fonts language Provides to Langpacks
https://fedoraproject.org/wiki/Changes/FontLanguageProvidesToLangpacks
== Summary ==
Move `Provides: font(:lang=...)` from fonts packages into the
`langpacks` package,
giving predictable default fonts for language scripts.
=== Motivation ===
Currently fonts packages has auto-generated `font(:lang=...)`
provides, which can be used as a dependency identifier to satisfy font
coverage required for a certain language requirement. This is used by
GTK application to install missing fonts via PackageKit for example.
However in practice it has not been very useful since usually there
are assorted multiple fonts that provide the language coverage and so
an arbitrary fonts of unknown quality would get selected, so the
mechanism is not unreliable.
This change uses instead the default fonts chosen in `langpacks` for
each language, to give reliable predictable default fonts for each
language and improve the user application experience around fonts.
== Owner ==
* Name: [[User:Tagoh| Akira TAGOH]], [[User:Pnemade| Parag Nemade]]
* Email: ta...@redhat.com, pnem...@redhat.com
== Detailed Description ==
The language based metadata for fonts packages was introduced in
Fedora 11. The idea being to provide a mechanism to find and install
a font for missing glyphs through PackageKit and was useful for
minority languages which might be missing default installed fonts
packages. But the user experience was generally not terribly good.
Users cannot predict which fonts will be installed. This often leads
to poor fonts choices installed, particularly for languages with too
many available fonts such as English, since the first font found
lexically will be arbitrarily chosen with gurantee of quality or
expected style.
This random dependency resolution sometimes introduces highly
unexpected results too - for example a font from an external
repository may get chosen by chance. This would be particularly
problematic when composing ISOs, eg when including EPEL.
So this Changes proposal aims to improve the user experience around
font dependencies by moving the meta-provides the `langpacks` package
instead. Langpacks contains various dependencies to use for certain
languages, including dependencies for default fonts. so it will
resolve the above issues.
Specifically speaking, currently font provides are generated like this:
$ fc-query -f %{=pkgkit} /usr/share/fonts/dejavu/DejaVuSans.ttf
font(dejavusans)
font(:lang=aa)
font(:lang=ab)
...
and at the build time, it is transformed to:
Provides: font(dejavusans)
Provides: font(:lang=aa)
Provides: font(:lang=ab)
...
After this proposal, the above result will be:
Provides: font(dejavusans)
and then add `Provides: font(:lang=...)` line to corresponding
sub-packages langpacks-core-*.
So asking for a font for a certain language through PackageKit will be
achieved by langpacks-core-* instead of a random font package.
== Benefit to Fedora ==
This proposal will provide reliable, predictable, and consistent font
dependencies.
== Scope ==
* Proposal owners:
** Update fontconfig to drop `font(:lang=...)` from the alias of the
formatter for `%{=pkgkit}`
** Add a line of `Provides: font(:lang=...)` to each
`langpacks-core-...`. For instance, `Provides: font(:lang=hi)` needs
to be added to `langpacks-core-hi`.
* Other developers: Release Engineers needs to rebuild all fonts
packages with the updated fontconfig package.
* Release engineering: [https://pagure.io/releng/issue/9132 #9132]
* Policies and guidelines: None
* Trademark approval: None
== Upgrade/compatibility impact ==
Some packages may be installed after upgrading if corresponding
langpacks-core-* packages isn't yet installed.
== How To Test ==
# Check that langpacks-core-* provide corresponding `font(:lang=...)`
using `rpm -q --provides`.
# Check that fonts packages no longer provide `font(:lang=...)`.
# Check that langpacks-core-* pulls in the default expected font for
the language.
== User Experience ==
Users should see better fonts chosen for languages when they install a
font to cover a certain language script through PackageKit or through
font meta dependencies of other packages.
== Dependencies ==
All fonts packages
== Contingency Plan ==
* Contingency mechanism: proposal owners will revert all the changes
and rebuild all fonts packages to add back the provides.
* Contingency deadline: the beta freeze
* Blocks release? No
* Blocks product? N/A
== Documentation ==
N/A
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Fedora 32 System-Wide Change proposal: Adopting sysusers.d format
https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format == Summary == Files in sysusers.d format will be used to declare systems users so it will be possible to introspect system users. Users will still be created using old-style useradd calls. == Owner == * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: zbyszek at in waw pl == Detailed Description == Many packages define their own user. Right now, those users are created in %pre by calling getent, useradd, and groupadd ([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation guidelines]). This will be changed to define users in the [https://www.freedesktop.org/software/systemd/man/sysusers.d.html sysusers.d format]. A macro will be provided to generate a %pre scriptlet that will call useradd and groupadd similarly to the scriptlets that are currently required by the packaging guidelines. In this proposal, systemd-sysusers will not be used to create the user. Using the sysusers.d format makes it easy to switch to systemd-sysusers as the implementation, and to experiment with different way to actually create the users based on the declarative syntax. This approach is heavily based on OpenSUSE's ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups guidelines]), but does not use separate rpm packages. I think using a %pre macro is good enough. == Benefit to Fedora == System users are declared by packages using a uniform syntax. The scriptlet part is standardized. Current implementation of creating users and groups is not changed, but may be switched easily in the future. For example, for container images, the macro may be replaced by a noop implementation, and the users created externally without installing the user creation tools in the container. Admins may easily introspect the system user list and which packages require users. Admins may easily override definitions of system users by providing appropriate sysusers.d files with higher priority. The difference between Fedora and other distros like OpenSUSE is reduced. == Scope == * Proposal owners: ** provide the macro and any helper tools ** submit a proposal to FPC ** convert a subset of packages * Other developers: ** FPC: review (and accept ;)) the guidelines changes ** other maintainers: convert other packages * Release engineering: n/a * Policies and guidelines: a pull request will be submitted * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == None. This change should be backwards and forwards compatible, i.e. unconverted packages can be still installed on new systems, and converted packages can be installed on older systems. == How To Test == This change should be mostly invisible to users. During installation, users should be created as appropriate before packages are installed. For packages that carry files owned by the user, check that the files are created with appropriate ownership by rpm. == User Experience == systemd-analyze cat-config sysusers.d/ shows the definitions of system users (incl. local overrides). == Dependencies == N/A == Contingency Plan == * Contingency mechanism: Revert to previous mechanism. This will require a revert of changes to the spec file and a rebuild of the package. * Contingency deadline: beta freeze * Blocks release? No * Blocks product? No == Documentation == TBD. == Release Notes == Not needed. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
I really love this idea because users (sysadmins) will get the ability to *not* restart some production-critical services on upgrade if they decide so without rebuilding package with removed scriptlets. I don't have suggestions about syntax, but whatever systemd upstream comes up with is good for me. On Thu, Jan 2, 2020 at 4:16 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_transaction > > == Summary == > > Scriptlets to restart each service that should be restarted in each > rpm package will be replaced by a declaration in the unit file and an > rpm transaction trigger that fires at the end and restarts all > services. > > == Owner == > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > * Email: zbyszek at in waw pl > > > == Detailed Description == > > Currently, when packages containing systemd services are upgraded, > they are restarted through %post scriptlets in each package. In other > words, the scriptlets specify which services should be restarted and > actually run the command to restart the service. An alternative > mechanism will be provided, whereby the unit file contains a setting > which specifies that the service should be restarted on upgrade, and a > %transfiletrigger in the systemd package will restart all services > marked so in upgraded packages at the end of transaction. > > To mark a services as "restart on upgrade" the unit file should > contain an option to mark it so. This can be either in the main > .service file, or e.g. in a drop-in file in > /usr/lib/systemd/system/.service.d/needs-restart.conf. > The exact name of the option should be something like > X-restart-on-upgrade=true|false. I'll take the proposal > for discussion in systemd upstream, since this is something that could > be used across distributions, and then the "X-" prefix could be > dropped and/or the name changed. > > == Benefit to Fedora == > > Which services should be restarted is specified declaratively and the > number of scriptlets is reduced. > > Admins may easily override this by providing appropriate drop-ins of > their own of higher priority. > > Services are restarted after the transaction is finished, all > libraries have been upgraded, and systemd configuration reloaded. This > solves https://bugzilla.redhat.com/show_bug.cgi?id=1614751, but also a > more general problem: a service may be restarted before any of its > dependencies (files and static content and whatnot) have been > upgraded, and while some contents from the old rpm are still on disk. > Restarting after all packages have been upgraded avoids this issue. > > In the future, restarting of services shall also be extended to user > managers (i.e. to restart all user services after the packages > providing those services have been upgraded). This is not part of this > proposal, but moving the information what to restart into systemd > units makes this much easier. > > == Scope == > * Proposal owners: > ** implement the relevant bits in the systemd package > ** submit a proposal to FPC > ** convert a subset of packages > > * Other developers: > ** FPC: review (and accept ;)) the guidelines changes > ** other maintainers: convert other packages > > * Release engineering: n/a > > * Policies and guidelines: a pull request will be submitted > > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > This change should be backwards compatible, i.e. unconverted packages > can be still installed on new systems, and services will be restarted > on upgrade like before. Converted packages may be installed on older > systems but will not get restarted on upgrades. > > == How To Test == > This change should be mostly invisible to users. Check that during > upgrades services are restarted and that no warnings are emitted. > > == User Experience == > N/A > > == Dependencies == > N/A > > == Contingency Plan == > > * Contingency mechanism: Revert to previous mechanism. This will > require a revert of changes to the spec file and a rebuild of the > package. > > * Contingency deadline: beta freeze > * Blocks release? No > * Blocks product? No > > == Documentation == > TBD. > > == Release Notes == > Not needed. > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: htt
Re: Fedora 32 System-Wide Change proposal: Systemd presets for user units
Do we have list of affected packages / services? I'd be more comfortable if we would have list of these and explicitly enabled mandatory ones so that we don't break composes and such. On Thu, Jan 2, 2020 at 4:15 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units > > == Summary == > > System units are managed through presets > [https://fedoraproject.org/wiki/Features/PackagePresets since F18] and > by policy, presets are carried by the fedora-release package. This > policy is now extended to user units. > > == Owner == > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > * Email: zbyszek at in waw pl > > == Detailed Description == > > The preset mechanism for user units was already in place, but we were > missing the actual preset files, and the default was "enable *" > instead of "disable *" as for system services. > > Systemd will now provide a > /usr/lib/systemd/user-preset/99-default-disable.preset that marks user > services as disabled by default. Any user services which should be > enabled will be to get an appropriate preset in > /usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific > file. Most packages already call into the preset mechanism, but those > which don't will be adjusted to do that. > > This is essentially a fix for > https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good > reason to treat user services different than system services in this > regard. On the systemd side this change is very simple, but all > packages that provide user units need to be reviewed to check if they > are enabled after the change if appropriate. > > == Benefit to Fedora == > > User and system services are handled in the same way. > > Local configuration may be used to override which services should be > enabled after upgrade. In particular, "local" in this context may mean > "per-spin" or "per-user". > > == Scope == > * Proposal owners: > ** review all packages that provide user services in Fedora and submit > PRs when changes are needed > ** add a new presets file to the fedora-release package for user units > ** submit a proposal to FPC to update the guidelines (essentially to > say "... and the same for user services."). > > * Other developers: > ** FPC: review (and accept ;)) the guidelines changes > ** other maintainers: verify that units in their packages are enabled > or not as appropriate after package installation > > * Release engineering: n/a > > * Policies and guidelines: a pull request will be submitted > > * Trademark approval: N/A (not needed for this Change) > > == Upgrade/compatibility impact == > Should not be user visible. Some units which are are currently enabled > by mistake will not be enabled anymore on new installations. > > == How To Test == > Install a new system (or uninstall and reinstall some packages). > Verify that the appropriate units are enabled for the user session. > > == User Experience == > N/A > > == Dependencies == > N/A > > == Contingency Plan == > > * Contingency mechanism: Revert the changes. > > * Contingency deadline: beta freeze > * Blocks release? No > * Blocks product? No > > == Documentation == > A pull request for the packaging guidelines will be submitted. > > == Release Notes == > Not needed. > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to devel-announce-le...@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-annou...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Golang 1.14
Do we really need to rebuild all thousand of packages given that most
of them are providing only noarch devel packages with sources? Don't
we need to rebuild only those which provide binaries?
On Thu, Jan 2, 2020 at 4:17 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/golang1.14
>
> == Summary ==
> Rebase of Golang package to upcoming version 1.14 in Fedora 32,
> including rebuild of all dependent packages(pre-release version of Go
> will be used for rebuild, if released version will not be available at
> the time of the mass rebuild).
>
> == Owner ==
> * Name: [[User:Jcajka| Jakub Čajka]]
> * Email: jca...@redhat.com
>
> == Detailed Description ==
>
> Rebase of Golang package to upcoming version 1.14 in Fedora 32. Golang
> 1.14 is schedule to be released in Feb 2020.
> Due to current nature and state of Go packages, rebuild of dependent
> package will be required to pick up the changes.
>
> == Benefit to Fedora ==
>
> Staying closely behind upstream by providing latest release of golang,
> which includes performance improvements and improvements in support
> for currently supported platforms among other bug fixes and new
> features. For complete list of changes see upstream change notes at
> https://tip.golang.org/doc/go1.14 . In result Fedora will be providing
> solid development platform for Go language.
>
> == Scope ==
> * Proposal owners: Rebase golang package in f32, help with resolving
> possible issues found during package rebuilds.
>
> * Other developers: Fix possible issues, with help from golang maintainers.
> * Release engineering: Rebuild of dependent packages as part of
> planned mass-rebuild. Tracking ticket
> https://pagure.io/releng/issue/9136
> * Policies and guidelines: N/A
> * Trademark approval: N/A
>
> == Upgrade/compatibility impact ==
> None
>
> == How To Test ==
> ;0.
> :a)Install golang 1.14 from rawhide and use it to build your
> application(s)/package(s).
> :b)Scratch build against rawhide.
> ;1.
> :Your application/package built using golang 1.14 should work as expected.
>
> == User Experience ==
> None
>
> == Dependencies ==
>
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'golang'
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'compiler(go-compiler)'
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'compiler(golang)'
> dnf repoquery -q --releasever=rawhide --disablerepo='*'
> --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> --enablerepo=updates-testing-source --archlist=src --whatrequires
> 'go-rpm-macros'
>
>
> Omitted due to the number of packages listed ~1100.
>
>
> Not all of listed require re-build as they might not ship binaries
> and/or do not use golang compiler during build, but only use Go rpm
> macros that pull it in to every build root.
>
> == Contingency Plan ==
> * Contingency mechanism:Reverting to golang version 1.13.X if
> significatnt issues are discovered.
> * Contingency deadline: Beta Freeze(?)
> * Blocks release? No
> * Blocks product? No
>
> == Documentation ==
> https://tip.golang.org/doc/go1.14
>
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@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-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format
On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format > > == Summary == > Files in sysusers.d format will be used to declare systems users so it > will be possible to introspect system users. Users will still be > created using old-style useradd calls. > > == Owner == > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > * Email: zbyszek at in waw pl > > == Detailed Description == > > Many packages define their own user. Right now, those users are > created in %pre by calling getent, useradd, and groupadd > ([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation > guidelines]). This will be changed to define users in the > [https://www.freedesktop.org/software/systemd/man/sysusers.d.html > sysusers.d format]. A macro will be provided to generate a %pre > scriptlet that will call useradd and groupadd similarly to the > scriptlets that are currently required by the packaging guidelines. > > In this proposal, systemd-sysusers will not be used to create the > user. Using the sysusers.d format makes it easy to switch to > systemd-sysusers as the implementation, and to experiment with > different way to actually create the users based on the declarative > syntax. > > This approach is heavily based on OpenSUSE's > ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups > guidelines]), but does not use separate rpm packages. I think using a > %pre macro is good enough. > > == Benefit to Fedora == > > System users are declared by packages using a uniform syntax. > > The scriptlet part is standardized. Current implementation of creating > users and groups is not changed, but may be switched easily in the > future. For example, for container images, the macro may be replaced > by a noop implementation, and the users created externally without > installing the user creation tools in the container. > > Admins may easily introspect the system user list and which packages > require users. > > Admins may easily override definitions of system users by providing > appropriate sysusers.d files with higher priority. > > The difference between Fedora and other distros like OpenSUSE is reduced. > While this *is* incrementally better than before, there *is* a reason for using separate RPM packages as openSUSE does. There are many cases where a user+group is actually shared across multiple packages, and having the user+group definition broken out into a subpackage means that it's easy for multiple packages to depend on it without having to depend on the program package. For example, in openSUSE, there is a wwwrun user paired with the www group (there's also a wwwrun group, but it doesn't matter quite that much). This user+group combination is used by *all* webservers. It also has a static ID, so that it's consistent across installs. Having this be a package instead of being a scriptlet run by each of the webservers means that it's easy for the webserver packages to depend on them. Moreover, the *definition* of the user+group is centralized, making it easier to audit and adjust over time. Also importantly, there's a dependency generator that generates user() and group() Provides for this, so that packages can just declare they need that user+group combo to exist first before the package can be installed. I would like us to be able to do that in Fedora too, as it would drastically simplify some of the odd issues we have with managing shared users and groups across multiple packages (web servers, language runtime environments, git services, etc.). For us, since we don't have the SUSE patches that make PreReq do things, the way we'd declare this with upstream RPM features would be: Requires: user(wwwrun) OrderWithRequires: user(wwwrun) That way, it's always installed before the package in question is. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Systemd presets for user units
On Thu, Jan 02, 2020 at 04:22:41PM +0100, Igor Gnatenko wrote: > Do we have list of affected packages / services? I'd be more > comfortable if we would have list of these and explicitly enabled > mandatory ones so that we don't break composes and such. Yes ... and no. I made a list a few months back, but I can't find it :( It'd need updating anyway. I'll try to post an up-to-date list sometime next week after I'm back from vacation. Zbyszek > On Thu, Jan 2, 2020 at 4:15 PM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units > > > > == Summary == > > > > System units are managed through presets > > [https://fedoraproject.org/wiki/Features/PackagePresets since F18] and > > by policy, presets are carried by the fedora-release package. This > > policy is now extended to user units. > > > > == Owner == > > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > > * Email: zbyszek at in waw pl > > > > == Detailed Description == > > > > The preset mechanism for user units was already in place, but we were > > missing the actual preset files, and the default was "enable *" > > instead of "disable *" as for system services. > > > > Systemd will now provide a > > /usr/lib/systemd/user-preset/99-default-disable.preset that marks user > > services as disabled by default. Any user services which should be > > enabled will be to get an appropriate preset in > > /usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific > > file. Most packages already call into the preset mechanism, but those > > which don't will be adjusted to do that. > > > > This is essentially a fix for > > https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good > > reason to treat user services different than system services in this > > regard. On the systemd side this change is very simple, but all > > packages that provide user units need to be reviewed to check if they > > are enabled after the change if appropriate. > > > > == Benefit to Fedora == > > > > User and system services are handled in the same way. > > > > Local configuration may be used to override which services should be > > enabled after upgrade. In particular, "local" in this context may mean > > "per-spin" or "per-user". > > > > == Scope == > > * Proposal owners: > > ** review all packages that provide user services in Fedora and submit > > PRs when changes are needed > > ** add a new presets file to the fedora-release package for user units > > ** submit a proposal to FPC to update the guidelines (essentially to > > say "... and the same for user services."). > > > > * Other developers: > > ** FPC: review (and accept ;)) the guidelines changes > > ** other maintainers: verify that units in their packages are enabled > > or not as appropriate after package installation > > > > * Release engineering: n/a > > > > * Policies and guidelines: a pull request will be submitted > > > > * Trademark approval: N/A (not needed for this Change) > > > > == Upgrade/compatibility impact == > > Should not be user visible. Some units which are are currently enabled > > by mistake will not be enabled anymore on new installations. > > > > == How To Test == > > Install a new system (or uninstall and reinstall some packages). > > Verify that the appropriate units are enabled for the user session. > > > > == User Experience == > > N/A > > > > == Dependencies == > > N/A > > > > == Contingency Plan == > > > > * Contingency mechanism: Revert the changes. > > > > * Contingency deadline: beta freeze > > * Blocks release? No > > * Blocks product? No > > > > == Documentation == > > A pull request for the packaging guidelines will be submitted. > > > > == Release Notes == > > Not needed. > > > > -- > > Ben Cotton > > He / Him / His > > Fedora Program Manager > > Red Hat > > TZ=America/Indiana/Indianapolis > > ___ > > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > > To unsubscribe send an email to devel-announce-le...@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-annou...@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/pr
Re: Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
On Thu, Jan 2, 2020 at 10:11 AM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_transaction > > == Summary == > > Scriptlets to restart each service that should be restarted in each > rpm package will be replaced by a declaration in the unit file and an > rpm transaction trigger that fires at the end and restarts all > services. > > == Owner == > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > * Email: zbyszek at in waw pl > > > == Detailed Description == > > Currently, when packages containing systemd services are upgraded, > they are restarted through %post scriptlets in each package. In other > words, the scriptlets specify which services should be restarted and > actually run the command to restart the service. An alternative > mechanism will be provided, whereby the unit file contains a setting > which specifies that the service should be restarted on upgrade, and a > %transfiletrigger in the systemd package will restart all services > marked so in upgraded packages at the end of transaction. > > To mark a services as "restart on upgrade" the unit file should > contain an option to mark it so. This can be either in the main > .service file, or e.g. in a drop-in file in > /usr/lib/systemd/system/.service.d/needs-restart.conf. > The exact name of the option should be something like > X-restart-on-upgrade=true|false. I'll take the proposal > for discussion in systemd upstream, since this is something that could > be used across distributions, and then the "X-" prefix could be > dropped and/or the name changed. > > == Benefit to Fedora == > > Which services should be restarted is specified declaratively and the > number of scriptlets is reduced. > > Admins may easily override this by providing appropriate drop-ins of > their own of higher priority. > > Services are restarted after the transaction is finished, all > libraries have been upgraded, and systemd configuration reloaded. This > solves https://bugzilla.redhat.com/show_bug.cgi?id=1614751, but also a > more general problem: a service may be restarted before any of its > dependencies (files and static content and whatnot) have been > upgraded, and while some contents from the old rpm are still on disk. > Restarting after all packages have been upgraded avoids this issue. > > In the future, restarting of services shall also be extended to user > managers (i.e. to restart all user services after the packages > providing those services have been upgraded). This is not part of this > proposal, but moving the information what to restart into systemd > units makes this much easier. > OpenMandriva actually implemented a variation of this two years ago, as well as a way to do preset runs through file triggers (more or less eliminating every single scriptlet for systemd units for ~90% of packages). I considered bringing this over to Fedora, but the mechanisms in systemd seem to still be a bit wobbly. Even with this proposal, how do we deal with system upgrades? In the system upgrade case, we don't really want these restarts to run, because the system will be rebooted anyway... These kinds of questions are why I didn't propose porting over what we did in OpenMandriva to Fedora. It's rather wasteful in a rather common case... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Golang 1.14
- Original Message -
> From: "Igor Gnatenko"
> To: "Development discussions related to Fedora"
>
> Sent: Thursday, January 2, 2020 4:24:44 PM
> Subject: Re: Fedora 32 System-Wide Change proposal: Golang 1.14
>
> Do we really need to rebuild all thousand of packages given that most
> of them are providing only noarch devel packages with sources? Don't
> we need to rebuild only those which provide binaries?
>
I don't disagree, but if the rebuild will be facilitated as part of the regular
mass-rebuild it will be "free". Other technical challenge is to find packages
that truly need rebuild(use Go compiler during the build, for tests and/or
building binaries) as that information is no longer present in the SRPM
metadata with the new Go packaging scheme(although even source only packages
should have their tests suites run, ideally, thus needing the compiler),
compiler is always pulled in to the build root via the new macros package.
JC
> On Thu, Jan 2, 2020 at 4:17 PM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/golang1.14
> >
> > == Summary ==
> > Rebase of Golang package to upcoming version 1.14 in Fedora 32,
> > including rebuild of all dependent packages(pre-release version of Go
> > will be used for rebuild, if released version will not be available at
> > the time of the mass rebuild).
> >
> > == Owner ==
> > * Name: [[User:Jcajka| Jakub Čajka]]
> > * Email: jca...@redhat.com
> >
> > == Detailed Description ==
> >
> > Rebase of Golang package to upcoming version 1.14 in Fedora 32. Golang
> > 1.14 is schedule to be released in Feb 2020.
> > Due to current nature and state of Go packages, rebuild of dependent
> > package will be required to pick up the changes.
> >
> > == Benefit to Fedora ==
> >
> > Staying closely behind upstream by providing latest release of golang,
> > which includes performance improvements and improvements in support
> > for currently supported platforms among other bug fixes and new
> > features. For complete list of changes see upstream change notes at
> > https://tip.golang.org/doc/go1.14 . In result Fedora will be providing
> > solid development platform for Go language.
> >
> > == Scope ==
> > * Proposal owners: Rebase golang package in f32, help with resolving
> > possible issues found during package rebuilds.
> >
> > * Other developers: Fix possible issues, with help from golang maintainers.
> > * Release engineering: Rebuild of dependent packages as part of
> > planned mass-rebuild. Tracking ticket
> > https://pagure.io/releng/issue/9136
> > * Policies and guidelines: N/A
> > * Trademark approval: N/A
> >
> > == Upgrade/compatibility impact ==
> > None
> >
> > == How To Test ==
> > ;0.
> > :a)Install golang 1.14 from rawhide and use it to build your
> > application(s)/package(s).
> > :b)Scratch build against rawhide.
> > ;1.
> > :Your application/package built using golang 1.14 should work as expected.
> >
> > == User Experience ==
> > None
> >
> > == Dependencies ==
> >
> > dnf repoquery -q --releasever=rawhide --disablerepo='*'
> > --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> > --enablerepo=updates-testing-source --archlist=src --whatrequires
> > 'golang'
> > dnf repoquery -q --releasever=rawhide --disablerepo='*'
> > --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> > --enablerepo=updates-testing-source --archlist=src --whatrequires
> > 'compiler(go-compiler)'
> > dnf repoquery -q --releasever=rawhide --disablerepo='*'
> > --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> > --enablerepo=updates-testing-source --archlist=src --whatrequires
> > 'compiler(golang)'
> > dnf repoquery -q --releasever=rawhide --disablerepo='*'
> > --qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
> > --enablerepo=updates-testing-source --archlist=src --whatrequires
> > 'go-rpm-macros'
> >
> >
> > Omitted due to the number of packages listed ~1100.
> >
> >
> > Not all of listed require re-build as they might not ship binaries
> > and/or do not use golang compiler during build, but only use Go rpm
> > macros that pull it in to every build root.
> >
> > == Contingency Plan ==
> > * Contingency mechanism:Reverting to golang version 1.13.X if
> > significatnt issues are discovered.
> > * Contingency deadline: Beta Freeze(?)
> > * Blocks release? No
> > * Blocks product? No
> >
> > == Documentation ==
> > https://tip.golang.org/doc/go1.14
> >
> >
> > --
> > Ben Cotton
> > He / Him / His
> > Fedora Program Manager
> > Red Hat
> > TZ=America/Indiana/Indianapolis
> > ___
> > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> > To unsubscribe send an email to
> > devel-announce-le...@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:
> > ht
Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format
On Thu, Jan 02, 2020 at 10:29:26AM -0500, Neal Gompa wrote: > On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format > > > > == Summary == > > Files in sysusers.d format will be used to declare systems users so it > > will be possible to introspect system users. Users will still be > > created using old-style useradd calls. > > > > == Owner == > > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > > * Email: zbyszek at in waw pl > > > > == Detailed Description == > > > > Many packages define their own user. Right now, those users are > > created in %pre by calling getent, useradd, and groupadd > > ([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation > > guidelines]). This will be changed to define users in the > > [https://www.freedesktop.org/software/systemd/man/sysusers.d.html > > sysusers.d format]. A macro will be provided to generate a %pre > > scriptlet that will call useradd and groupadd similarly to the > > scriptlets that are currently required by the packaging guidelines. > > > > In this proposal, systemd-sysusers will not be used to create the > > user. Using the sysusers.d format makes it easy to switch to > > systemd-sysusers as the implementation, and to experiment with > > different way to actually create the users based on the declarative > > syntax. > > > > This approach is heavily based on OpenSUSE's > > ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups > > guidelines]), but does not use separate rpm packages. I think using a > > %pre macro is good enough. > > > > == Benefit to Fedora == > > > > System users are declared by packages using a uniform syntax. > > > > The scriptlet part is standardized. Current implementation of creating > > users and groups is not changed, but may be switched easily in the > > future. For example, for container images, the macro may be replaced > > by a noop implementation, and the users created externally without > > installing the user creation tools in the container. > > > > Admins may easily introspect the system user list and which packages > > require users. > > > > Admins may easily override definitions of system users by providing > > appropriate sysusers.d files with higher priority. > > > > The difference between Fedora and other distros like OpenSUSE is reduced. > > > > While this *is* incrementally better than before, there *is* a reason > for using separate RPM packages as openSUSE does. There are many cases > where a user+group is actually shared across multiple packages, and > having the user+group definition broken out into a subpackage means > that it's easy for multiple packages to depend on it without having to > depend on the program package. For those cases, a separate package can be split out, similarly to any other case of resources shared between packages. I didn't want to make the split mandatory because I assumed that sharing a user between completely independent packages is something of a fringe case... (The case when there's a single "main" package and a bunch of add-on packages which use the same user doesn't count here, because in that case it's easy enough to define the user in the "main" package.) Apart from web servers, what are the use cases? > For example, in openSUSE, there is a wwwrun user paired with the www > group (there's also a wwwrun group, but it doesn't matter quite that > much). This user+group combination is used by *all* webservers. > It also has a static ID, so that it's consistent across installs. Fedora pretty much gave up on static UIDs a while back. We use "dynamic" allocation pretty much all the time. Nevertheless, I don't think that static vs. dynamic matters for this, since all the discussed mechanisms (current useradd+groupadd, proposed mechanism, or opensuse mechanism with separate packages) would give the same id allocations. > Moreover, the *definition* of the user+group is centralized, > making it easier to audit and adjust over time. I don't grok this sentence. In my proposal the definition of a user is a single sysusers.d file. It is owned by some specific package, and in this sense the definition is centralized (unique). IIUC, opensuse has a similar setup, with the main difference being that the file is shunted to a separate package, i.e. there is just as much "centralization". > Also importantly, > there's a dependency generator that generates user() and group() > Provides for this, so that packages can just declare they need that > user+group combo to exist first before the package can be installed. This can be added too. > I would like us to be able to do that in Fedora too, as it would > drastically simplify some of the odd issues we have with managing > shared users and groups across multiple packages (web servers, > language runtime environments, git services, etc.). I was not aware of those problems. Can you give me some pointers to those
Updating pytest to 5: ~30 packages FTBFS
Hello, I'd like to get pytest updated to 5.x in rawhide. https://src.fedoraproject.org/rpms/pytest/pull-request/15 Several deprecated things were removed from that version and 31 packages fail to build from source with pytest 5 (while building fine with pytest 4). The packages are built in: http://copr.fedorainfracloud.org/coprs/churchyard/pytest-4/ http://copr.fedorainfracloud.org/coprs/churchyard/pytest-5/ I would appreciate your help with fixing the packages. Several notable packages: scipy fix: https://src.fedoraproject.org/rpms/scipy/pull-request/15 python-requests upstream fix: https://github.com/psf/requests/issues/5304 python-ipyparallel and python-daskbuild somehow weirdly, maybe they will finish. python-pytest-* - there might be some newer versions available that work All packages: Maintainers by package: ansible kevin toshio wzzrd fabric orphan pylast peter python-atomicwrites mathstuf mbaldessari python-beanbag sochotni python-behavechurchyard pschindl python-billiard fab mrunge ngompa pingou pjp rmarko sundaram python-colcon-bazel cottsay python-dask qulogic python-flask codeblock fcami hguemar hushan python-flask-caching lbrabec python-flask-sqlalchemy hguemar kumarpraveen pjp ralph sundaram tflink python-hpack eclipseo python-html5lib churchyard pjp sagitter salimma sundaram python-invokepghmcfc python-ipyparallel ellert python-lz4 jgu orion python-mako abompard bowlofeggs cverna ignatenkobrain kylev lmacken python-mdp zbyszek python-paramiko athmane ignatenkobrain ivazquez orion pghmcfc sgallagh python-pdir2 carlwgeorge python-pyrsistentdecathorpe devrim itamarjp python-pytest-covcstratak orion ttomecek python-pytest-faulthandler dkrejci lbalhar python-pytest-lazy-fixture ankursinha python-pytest-relaxed athmane python-pytest-xdist swt2c python-requests abompard cstratak jcline ralph sagarun python-testinfra wakko666 python-whitenoisepiotrp scipycstratak jspaleta orion tomspur ttomecek Packages by maintainer: abompard python-mako python-requests ankursinha python-pytest-lazy-fixture athmanepython-paramiko python-pytest-relaxed bowlofeggs python-mako carlwgeorge python-pdir2 churchyard python-behave python-html5lib codeblock python-flask cottsaypython-colcon-bazel cstratak python-pytest-cov python-requests scipy cverna python-mako decathorpe python-pyrsistent devrim python-pyrsistent dkrejcipython-pytest-faulthandler eclipseo python-hpack ellert python-ipyparallel fabpython-billiard fcami python-flask hguemarpython-flask python-flask-sqlalchemy hushan python-flask ignatenkobrain python-mako python-paramiko itamarjp python-pyrsistent ivazquez python-paramiko jcline python-requests jgupython-lz4 jspaleta scipy kevin ansible kumarpraveen python-flask-sqlalchemy kylev python-mako lbalharpython-pytest-faulthandler lbrabecpython-flask-caching lmackenpython-mako mathstuf python-atomicwrites mbaldessari python-atomicwrites mrunge python-billiard ngompa python-billiard orion python-lz4 python-paramiko python-pytest-cov scipy orphan fabric peter pylast pghmcfcpython-invoke python-paramiko pingou python-billiard piotrp python-whitenoise pjppython-billiard python-flask-sqlalchemy python-html5lib pschindl python-behave qulogicpython-dask ralph python-flask-sqlalchemy python-requests rmarko python-billiard sagarunpython-requests sagitter python-html5lib salimmapython-html5lib sgallagh python-paramiko sochotni python-beanbag sundaram python-billiard python-flask-sqlalchemy python-html5lib swt2c python-pytest-xdist tflink python-flask-sqlalchemy tomspurscipy toshio ansible ttomecek python-pytest-cov scipy wakko666 python-testinfra wzzrd ansible zbyszekpython-mdp -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Updating pytest to 5: ~30 packages FTBFS
These 2 packages will break: python-pikepdf-1.7.0-2.fc32.src: (python3dist(pytest) >= 3.10.1 with python3dist(pytest) < 5) python3-pytest-relaxed-1.1.5-1.fc32.noarch: python3.8dist(pytest) < 5 On Thu, Jan 2, 2020 at 5:09 PM Miro Hrončok wrote: > > Hello, > > I'd like to get pytest updated to 5.x in rawhide. > > https://src.fedoraproject.org/rpms/pytest/pull-request/15 > > Several deprecated things were removed from that version and 31 packages fail > to > build from source with pytest 5 (while building fine with pytest 4). > > > The packages are built in: > > http://copr.fedorainfracloud.org/coprs/churchyard/pytest-4/ > http://copr.fedorainfracloud.org/coprs/churchyard/pytest-5/ > > I would appreciate your help with fixing the packages. > > > > Several notable packages: > > scipy fix: https://src.fedoraproject.org/rpms/scipy/pull-request/15 > python-requests upstream fix: https://github.com/psf/requests/issues/5304 > > python-ipyparallel and > python-daskbuild somehow weirdly, maybe they will finish. > > python-pytest-* - there might be some newer versions available that work > > > > All packages: > > Maintainers by package: > ansible kevin toshio wzzrd > fabric orphan > pylast peter > python-atomicwrites mathstuf mbaldessari > python-beanbag sochotni > python-behavechurchyard pschindl > python-billiard fab mrunge ngompa pingou pjp rmarko sundaram > python-colcon-bazel cottsay > python-dask qulogic > python-flask codeblock fcami hguemar hushan > python-flask-caching lbrabec > python-flask-sqlalchemy hguemar kumarpraveen pjp ralph sundaram tflink > python-hpack eclipseo > python-html5lib churchyard pjp sagitter salimma sundaram > python-invokepghmcfc > python-ipyparallel ellert > python-lz4 jgu orion > python-mako abompard bowlofeggs cverna ignatenkobrain kylev lmacken > python-mdp zbyszek > python-paramiko athmane ignatenkobrain ivazquez orion pghmcfc sgallagh > python-pdir2 carlwgeorge > python-pyrsistentdecathorpe devrim itamarjp > python-pytest-covcstratak orion ttomecek > python-pytest-faulthandler dkrejci lbalhar > python-pytest-lazy-fixture ankursinha > python-pytest-relaxed athmane > python-pytest-xdist swt2c > python-requests abompard cstratak jcline ralph sagarun > python-testinfra wakko666 > python-whitenoisepiotrp > scipycstratak jspaleta orion tomspur ttomecek > > Packages by maintainer: > abompard python-mako python-requests > ankursinha python-pytest-lazy-fixture > athmanepython-paramiko python-pytest-relaxed > bowlofeggs python-mako > carlwgeorge python-pdir2 > churchyard python-behave python-html5lib > codeblock python-flask > cottsaypython-colcon-bazel > cstratak python-pytest-cov python-requests scipy > cverna python-mako > decathorpe python-pyrsistent > devrim python-pyrsistent > dkrejcipython-pytest-faulthandler > eclipseo python-hpack > ellert python-ipyparallel > fabpython-billiard > fcami python-flask > hguemarpython-flask python-flask-sqlalchemy > hushan python-flask > ignatenkobrain python-mako python-paramiko > itamarjp python-pyrsistent > ivazquez python-paramiko > jcline python-requests > jgupython-lz4 > jspaleta scipy > kevin ansible > kumarpraveen python-flask-sqlalchemy > kylev python-mako > lbalharpython-pytest-faulthandler > lbrabecpython-flask-caching > lmackenpython-mako > mathstuf python-atomicwrites > mbaldessari python-atomicwrites > mrunge python-billiard > ngompa python-billiard > orion python-lz4 python-paramiko python-pytest-cov scipy > orphan fabric > peter pylast > pghmcfcpython-invoke python-paramiko > pingou python-billiard > piotrp python-whitenoise > pjppython-billiard python-flask-sqlalchemy python-html5lib > pschindl python-behave > qulogicpython-dask > ralph python-flask-sqlalchemy python-requests > rmarko python-billiard > sagarunpython-requests > sagitter python-html5lib > salimmapython-html5lib > sgallagh python-paramiko > sochotni python-beanbag > sundaram python-billiard python-flask-sqlalchemy python-html5lib > swt2c python-pytest-xdist > tflink python-flask-sqlalchemy > tomspurscipy > toshio ansible > ttomecek python-pytest-cov scipy > wakko666 python-testinfra > wzzrd ansible > zbyszekpython-mdp > > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedorapr
Re: Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
On Thu, Jan 02, 2020 at 10:45:07AM -0500, Neal Gompa wrote: > On Thu, Jan 2, 2020 at 10:11 AM Ben Cotton wrote: > > > > https://fedoraproject.org/wiki/Changes/Restart_services_at_end_of_rpm_transaction > > > > == Summary == > > > > Scriptlets to restart each service that should be restarted in each > > rpm package will be replaced by a declaration in the unit file and an > > rpm transaction trigger that fires at the end and restarts all > > services. > > > > == Owner == > > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > > * Email: zbyszek at in waw pl > > > > > > == Detailed Description == > > > > Currently, when packages containing systemd services are upgraded, > > they are restarted through %post scriptlets in each package. In other > > words, the scriptlets specify which services should be restarted and > > actually run the command to restart the service. An alternative > > mechanism will be provided, whereby the unit file contains a setting > > which specifies that the service should be restarted on upgrade, and a > > %transfiletrigger in the systemd package will restart all services > > marked so in upgraded packages at the end of transaction. > > > > To mark a services as "restart on upgrade" the unit file should > > contain an option to mark it so. This can be either in the main > > .service file, or e.g. in a drop-in file in > > /usr/lib/systemd/system/.service.d/needs-restart.conf. > > The exact name of the option should be something like > > X-restart-on-upgrade=true|false. I'll take the proposal > > for discussion in systemd upstream, since this is something that could > > be used across distributions, and then the "X-" prefix could be > > dropped and/or the name changed. > > > > == Benefit to Fedora == > > > > Which services should be restarted is specified declaratively and the > > number of scriptlets is reduced. > > > > Admins may easily override this by providing appropriate drop-ins of > > their own of higher priority. > > > > Services are restarted after the transaction is finished, all > > libraries have been upgraded, and systemd configuration reloaded. This > > solves https://bugzilla.redhat.com/show_bug.cgi?id=1614751, but also a > > more general problem: a service may be restarted before any of its > > dependencies (files and static content and whatnot) have been > > upgraded, and while some contents from the old rpm are still on disk. > > Restarting after all packages have been upgraded avoids this issue. > > > > In the future, restarting of services shall also be extended to user > > managers (i.e. to restart all user services after the packages > > providing those services have been upgraded). This is not part of this > > proposal, but moving the information what to restart into systemd > > units makes this much easier. > > > > OpenMandriva actually implemented a variation of this two years ago, > as well as a way to do preset runs through file triggers (more or less > eliminating every single scriptlet for systemd units for ~90% of > packages). I considered bringing this over to Fedora, but the > mechanisms in systemd seem to still be a bit wobbly. We don't do presets through file triggers because we the scriptlet is conditionalized to only do the preset on initial package installation. But if it is possible to do something equivalent (or better?) through a file trigger, that'd be great. I'm all ears. > Even with this proposal, how do we deal with system upgrades? In the > system upgrade case, we don't really want these restarts to run, > because the system will be rebooted anyway... These kinds of questions > are why I didn't propose porting over what we did in OpenMandriva to > Fedora. It's rather wasteful in a rather common case... I'm not sure if skipping restarts on upgrade is worth the trouble. It should be quite simple to implement (e.g. by having the restart scriptlet check if the systemd target has been diverted to system-update.target), but restarting of services would most likely take only a small fraction of time required for the upgrade anyway. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format
On Thu, Jan 2, 2020 at 11:04 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jan 02, 2020 at 10:29:26AM -0500, Neal Gompa wrote: > > On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote: > > > > > > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format > > > > > > == Summary == > > > Files in sysusers.d format will be used to declare systems users so it > > > will be possible to introspect system users. Users will still be > > > created using old-style useradd calls. > > > > > > == Owner == > > > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > > > * Email: zbyszek at in waw pl > > > > > > == Detailed Description == > > > > > > Many packages define their own user. Right now, those users are > > > created in %pre by calling getent, useradd, and groupadd > > > ([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation > > > guidelines]). This will be changed to define users in the > > > [https://www.freedesktop.org/software/systemd/man/sysusers.d.html > > > sysusers.d format]. A macro will be provided to generate a %pre > > > scriptlet that will call useradd and groupadd similarly to the > > > scriptlets that are currently required by the packaging guidelines. > > > > > > In this proposal, systemd-sysusers will not be used to create the > > > user. Using the sysusers.d format makes it easy to switch to > > > systemd-sysusers as the implementation, and to experiment with > > > different way to actually create the users based on the declarative > > > syntax. > > > > > > This approach is heavily based on OpenSUSE's > > > ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups > > > guidelines]), but does not use separate rpm packages. I think using a > > > %pre macro is good enough. > > > > > > == Benefit to Fedora == > > > > > > System users are declared by packages using a uniform syntax. > > > > > > The scriptlet part is standardized. Current implementation of creating > > > users and groups is not changed, but may be switched easily in the > > > future. For example, for container images, the macro may be replaced > > > by a noop implementation, and the users created externally without > > > installing the user creation tools in the container. > > > > > > Admins may easily introspect the system user list and which packages > > > require users. > > > > > > Admins may easily override definitions of system users by providing > > > appropriate sysusers.d files with higher priority. > > > > > > The difference between Fedora and other distros like OpenSUSE is reduced. > > > > > > > While this *is* incrementally better than before, there *is* a reason > > for using separate RPM packages as openSUSE does. There are many cases > > where a user+group is actually shared across multiple packages, and > > having the user+group definition broken out into a subpackage means > > that it's easy for multiple packages to depend on it without having to > > depend on the program package. > > For those cases, a separate package can be split out, similarly to any > other case of resources shared between packages. I didn't want to make > the split mandatory because I assumed that sharing a user between > completely independent packages is something of a fringe case... > (The case when there's a single "main" package and a bunch of add-on > packages which use the same user doesn't count here, because in that > case it's easy enough to define the user in the "main" package.) > Apart from web servers, what are the use cases? > > > For example, in openSUSE, there is a wwwrun user paired with the www > > group (there's also a wwwrun group, but it doesn't matter quite that > > much). This user+group combination is used by *all* webservers. > > > It also has a static ID, so that it's consistent across installs. > > Fedora pretty much gave up on static UIDs a while back. We use "dynamic" > allocation pretty much all the time. Nevertheless, I don't think that > static vs. dynamic matters for this, since all the discussed mechanisms > (current useradd+groupadd, proposed mechanism, or opensuse mechanism > with separate packages) would give the same id allocations. > This is not true. Static IDs are hard when you potentially have multiple packages defining the same user/group, but if they're shared somehow, then static IDs are easier. We do not require static IDs by default, and indeed most are non-static because they don't need to be static. But some are, because if they aren't, things break (mock, for example). > > Moreover, the *definition* of the user+group is centralized, > > making it easier to audit and adjust over time. > > I don't grok this sentence. In my proposal the definition of a user is > a single sysusers.d file. It is owned by some specific package, and in > this sense the definition is centralized (unique). IIUC, opensuse has > a similar setup, with the main difference being that the file is shunted > to a separate package, i.e. there is just as much "
Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format
On Thu, Jan 02, 2020 at 11:15:57AM -0500, Neal Gompa wrote: > On Thu, Jan 2, 2020 at 11:04 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Thu, Jan 02, 2020 at 10:29:26AM -0500, Neal Gompa wrote: > > > On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote: > > > > > > > > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format > > > > > > > > == Summary == > > > > Files in sysusers.d format will be used to declare systems users so it > > > > will be possible to introspect system users. Users will still be > > > > created using old-style useradd calls. > > > > > > > > == Owner == > > > > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > > > > * Email: zbyszek at in waw pl > > > > > > > > == Detailed Description == > > > > > > > > Many packages define their own user. Right now, those users are > > > > created in %pre by calling getent, useradd, and groupadd > > > > ([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation > > > > guidelines]). This will be changed to define users in the > > > > [https://www.freedesktop.org/software/systemd/man/sysusers.d.html > > > > sysusers.d format]. A macro will be provided to generate a %pre > > > > scriptlet that will call useradd and groupadd similarly to the > > > > scriptlets that are currently required by the packaging guidelines. > > > > > > > > In this proposal, systemd-sysusers will not be used to create the > > > > user. Using the sysusers.d format makes it easy to switch to > > > > systemd-sysusers as the implementation, and to experiment with > > > > different way to actually create the users based on the declarative > > > > syntax. > > > > > > > > This approach is heavily based on OpenSUSE's > > > > ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups > > > > guidelines]), but does not use separate rpm packages. I think using a > > > > %pre macro is good enough. > > > > > > > > == Benefit to Fedora == > > > > > > > > System users are declared by packages using a uniform syntax. > > > > > > > > The scriptlet part is standardized. Current implementation of creating > > > > users and groups is not changed, but may be switched easily in the > > > > future. For example, for container images, the macro may be replaced > > > > by a noop implementation, and the users created externally without > > > > installing the user creation tools in the container. > > > > > > > > Admins may easily introspect the system user list and which packages > > > > require users. > > > > > > > > Admins may easily override definitions of system users by providing > > > > appropriate sysusers.d files with higher priority. > > > > > > > > The difference between Fedora and other distros like OpenSUSE is > > > > reduced. > > > > > > > > > > While this *is* incrementally better than before, there *is* a reason > > > for using separate RPM packages as openSUSE does. There are many cases > > > where a user+group is actually shared across multiple packages, and > > > having the user+group definition broken out into a subpackage means > > > that it's easy for multiple packages to depend on it without having to > > > depend on the program package. > > > > For those cases, a separate package can be split out, similarly to any > > other case of resources shared between packages. I didn't want to make > > the split mandatory because I assumed that sharing a user between > > completely independent packages is something of a fringe case... > > (The case when there's a single "main" package and a bunch of add-on > > packages which use the same user doesn't count here, because in that > > case it's easy enough to define the user in the "main" package.) > > Apart from web servers, what are the use cases? > > > > > For example, in openSUSE, there is a wwwrun user paired with the www > > > group (there's also a wwwrun group, but it doesn't matter quite that > > > much). This user+group combination is used by *all* webservers. > > > > > It also has a static ID, so that it's consistent across installs. > > > > Fedora pretty much gave up on static UIDs a while back. We use "dynamic" > > allocation pretty much all the time. Nevertheless, I don't think that > > static vs. dynamic matters for this, since all the discussed mechanisms > > (current useradd+groupadd, proposed mechanism, or opensuse mechanism > > with separate packages) would give the same id allocations. > > > > This is not true. What exactly? > Static IDs are hard when you potentially have > multiple packages defining the same user/group, but if they're shared > somehow, then static IDs are easier. We do not require static IDs by > default, and indeed most are non-static because they don't need to be > static. But some are, because if they aren't, things break (mock, for > example). I agree that static IDs have their uses. By "gave up" I only meant that they are rarely used and new ones are rarely added, not that they are never used. I guess we are in total agreement here
Re: Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
> The exact name of the option should be something like > X-restart-on-upgrade=true|false. I'll take the proposal > for discussion in systemd upstream, since this is something that could > be used across distributions, and then the "X-" prefix could be > dropped and/or the name changed. > [...] > ** other maintainers: convert other packages Please don't push hard to get this widely adopted before the name is final. Don't make packagers change their packages and then have them change the name later. Let the feature remain experimental and optional until the permanent name has been decided and implemented. Other than that, the proposal sounds good to me. Björn Persson pgpXqbFJdnq32.pgp Description: OpenPGP digital signatur ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
On Thu, Jan 2, 2020 at 10:14 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Thu, Jan 02, 2020 at 10:45:07AM -0500, Neal Gompa wrote: > > On Thu, Jan 2, 2020 at 10:11 AM Ben Cotton wrote: > > Even with this proposal, how do we deal with system upgrades? In the > > system upgrade case, we don't really want these restarts to run, > > because the system will be rebooted anyway... These kinds of questions > > are why I didn't propose porting over what we did in OpenMandriva to > > Fedora. It's rather wasteful in a rather common case... > > I'm not sure if skipping restarts on upgrade is worth the trouble. It > should be quite simple to implement (e.g. by having the restart scriptlet > check if the systemd target has been diverted to system-update.target), > but restarting of services would most likely take only a small fraction > of time required for the upgrade anyway. > Maybe it should only restart the service if it's already running. In the case of an upgrade it's a special target, right? Actually that's probably a good idea anyway. If I have stopped a service (even if it's enabled) then it should not be restarted on upgrade. Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Move fonts language Provides to Langpacks
I think it would be useful to mention in the change page that
langpacks-core-* already depend on "good quality font". If that is
already there, I apologize.
Another thing which is not mentioned on the change page is that you
are going to drop Requires: font(:lang=…) from fontconfig (otherwise
it is going to pull all langpacks-core-* packages).
Otherwise I'm happy with this change since this will finally solve the
problem where you install some game like teeworlds, get some fonts
pulled in and autoremove will never remove it since fontconfig depend
on font(:lang=xx) and libsolv never auto-removes "alternative"
packages. So you never remove fonts unless explicitly ask DNF to do
so.
On Thu, Jan 2, 2020 at 4:17 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/FontLanguageProvidesToLangpacks
>
> == Summary ==
> Move `Provides: font(:lang=...)` from fonts packages into the
> `langpacks` package,
> giving predictable default fonts for language scripts.
>
> === Motivation ===
> Currently fonts packages has auto-generated `font(:lang=...)`
> provides, which can be used as a dependency identifier to satisfy font
> coverage required for a certain language requirement. This is used by
> GTK application to install missing fonts via PackageKit for example.
> However in practice it has not been very useful since usually there
> are assorted multiple fonts that provide the language coverage and so
> an arbitrary fonts of unknown quality would get selected, so the
> mechanism is not unreliable.
>
> This change uses instead the default fonts chosen in `langpacks` for
> each language, to give reliable predictable default fonts for each
> language and improve the user application experience around fonts.
>
> == Owner ==
> * Name: [[User:Tagoh| Akira TAGOH]], [[User:Pnemade| Parag Nemade]]
> * Email: ta...@redhat.com, pnem...@redhat.com
>
>
> == Detailed Description ==
> The language based metadata for fonts packages was introduced in
> Fedora 11. The idea being to provide a mechanism to find and install
> a font for missing glyphs through PackageKit and was useful for
> minority languages which might be missing default installed fonts
> packages. But the user experience was generally not terribly good.
>
> Users cannot predict which fonts will be installed. This often leads
> to poor fonts choices installed, particularly for languages with too
> many available fonts such as English, since the first font found
> lexically will be arbitrarily chosen with gurantee of quality or
> expected style.
> This random dependency resolution sometimes introduces highly
> unexpected results too - for example a font from an external
> repository may get chosen by chance. This would be particularly
> problematic when composing ISOs, eg when including EPEL.
>
> So this Changes proposal aims to improve the user experience around
> font dependencies by moving the meta-provides the `langpacks` package
> instead. Langpacks contains various dependencies to use for certain
> languages, including dependencies for default fonts. so it will
> resolve the above issues.
>
> Specifically speaking, currently font provides are generated like this:
>
> $ fc-query -f %{=pkgkit} /usr/share/fonts/dejavu/DejaVuSans.ttf
> font(dejavusans)
> font(:lang=aa)
> font(:lang=ab)
> ...
>
>
> and at the build time, it is transformed to:
>
> Provides: font(dejavusans)
> Provides: font(:lang=aa)
> Provides: font(:lang=ab)
> ...
>
>
> After this proposal, the above result will be:
>
> Provides: font(dejavusans)
>
>
> and then add `Provides: font(:lang=...)` line to corresponding
> sub-packages langpacks-core-*.
>
> So asking for a font for a certain language through PackageKit will be
> achieved by langpacks-core-* instead of a random font package.
>
> == Benefit to Fedora ==
> This proposal will provide reliable, predictable, and consistent font
> dependencies.
>
> == Scope ==
> * Proposal owners:
> ** Update fontconfig to drop `font(:lang=...)` from the alias of the
> formatter for `%{=pkgkit}`
> ** Add a line of `Provides: font(:lang=...)` to each
> `langpacks-core-...`. For instance, `Provides: font(:lang=hi)` needs
> to be added to `langpacks-core-hi`.
>
> * Other developers: Release Engineers needs to rebuild all fonts
> packages with the updated fontconfig package.
> * Release engineering: [https://pagure.io/releng/issue/9132 #9132]
> * Policies and guidelines: None
> * Trademark approval: None
>
>
> == Upgrade/compatibility impact ==
> Some packages may be installed after upgrading if corresponding
> langpacks-core-* packages isn't yet installed.
>
> == How To Test ==
> # Check that langpacks-core-* provide corresponding `font(:lang=...)`
> using `rpm -q --provides`.
> # Check that fonts packages no longer provide `font(:lang=...)`.
> # Check that langpacks-core-* pulls in the default expected font for
> the language.
>
> == User Experience ==
> Users should see better fonts chosen for languages when they install a
> font to cover a certai
Re: Fedora 32 System-Wide Change proposal: Adopting sysusers.d format
On Thu, Jan 2, 2020 at 11:39 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jan 02, 2020 at 11:15:57AM -0500, Neal Gompa wrote: > > On Thu, Jan 2, 2020 at 11:04 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Thu, Jan 02, 2020 at 10:29:26AM -0500, Neal Gompa wrote: > > > > On Thu, Jan 2, 2020 at 10:14 AM Ben Cotton wrote: > > > > > > > > > > https://fedoraproject.org/wiki/Changes/Adopting_sysusers.d_format > > > > > > > > > > == Summary == > > > > > Files in sysusers.d format will be used to declare systems users so it > > > > > will be possible to introspect system users. Users will still be > > > > > created using old-style useradd calls. > > > > > > > > > > == Owner == > > > > > * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] > > > > > * Email: zbyszek at in waw pl > > > > > > > > > > == Detailed Description == > > > > > > > > > > Many packages define their own user. Right now, those users are > > > > > created in %pre by calling getent, useradd, and groupadd > > > > > ([https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_dynamic_allocation > > > > > guidelines]). This will be changed to define users in the > > > > > [https://www.freedesktop.org/software/systemd/man/sysusers.d.html > > > > > sysusers.d format]. A macro will be provided to generate a %pre > > > > > scriptlet that will call useradd and groupadd similarly to the > > > > > scriptlets that are currently required by the packaging guidelines. > > > > > > > > > > In this proposal, systemd-sysusers will not be used to create the > > > > > user. Using the sysusers.d format makes it easy to switch to > > > > > systemd-sysusers as the implementation, and to experiment with > > > > > different way to actually create the users based on the declarative > > > > > syntax. > > > > > > > > > > This approach is heavily based on OpenSUSE's > > > > > ([https://en.opensuse.org/openSUSE:Packaging_guidelines#Users_and_Groups > > > > > guidelines]), but does not use separate rpm packages. I think using a > > > > > %pre macro is good enough. > > > > > > > > > > == Benefit to Fedora == > > > > > > > > > > System users are declared by packages using a uniform syntax. > > > > > > > > > > The scriptlet part is standardized. Current implementation of creating > > > > > users and groups is not changed, but may be switched easily in the > > > > > future. For example, for container images, the macro may be replaced > > > > > by a noop implementation, and the users created externally without > > > > > installing the user creation tools in the container. > > > > > > > > > > Admins may easily introspect the system user list and which packages > > > > > require users. > > > > > > > > > > Admins may easily override definitions of system users by providing > > > > > appropriate sysusers.d files with higher priority. > > > > > > > > > > The difference between Fedora and other distros like OpenSUSE is > > > > > reduced. > > > > > > > > > > > > > While this *is* incrementally better than before, there *is* a reason > > > > for using separate RPM packages as openSUSE does. There are many cases > > > > where a user+group is actually shared across multiple packages, and > > > > having the user+group definition broken out into a subpackage means > > > > that it's easy for multiple packages to depend on it without having to > > > > depend on the program package. > > > > > > For those cases, a separate package can be split out, similarly to any > > > other case of resources shared between packages. I didn't want to make > > > the split mandatory because I assumed that sharing a user between > > > completely independent packages is something of a fringe case... > > > (The case when there's a single "main" package and a bunch of add-on > > > packages which use the same user doesn't count here, because in that > > > case it's easy enough to define the user in the "main" package.) > > > Apart from web servers, what are the use cases? > > > > > > > For example, in openSUSE, there is a wwwrun user paired with the www > > > > group (there's also a wwwrun group, but it doesn't matter quite that > > > > much). This user+group combination is used by *all* webservers. > > > > > > > It also has a static ID, so that it's consistent across installs. > > > > > > Fedora pretty much gave up on static UIDs a while back. We use "dynamic" > > > allocation pretty much all the time. Nevertheless, I don't think that > > > static vs. dynamic matters for this, since all the discussed mechanisms > > > (current useradd+groupadd, proposed mechanism, or opensuse mechanism > > > with separate packages) would give the same id allocations. > > > > > > > This is not true. > What exactly? > > > Static IDs are hard when you potentially have > > multiple packages defining the same user/group, but if they're shared > > somehow, then static IDs are easier. We do not require static IDs by > > default, and indeed most are non-static because they don't need to be > > static. But so
Re: Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
On Thu, 2020-01-02 at 11:18 -0600, Richard Shaw wrote: > On Thu, Jan 2, 2020 at 10:14 AM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > > > On Thu, Jan 02, 2020 at 10:45:07AM -0500, Neal Gompa wrote: > > > On Thu, Jan 2, 2020 at 10:11 AM Ben Cotton wrote: > > > Even with this proposal, how do we deal with system upgrades? In the > > > system upgrade case, we don't really want these restarts to run, > > > because the system will be rebooted anyway... These kinds of questions > > > are why I didn't propose porting over what we did in OpenMandriva to > > > Fedora. It's rather wasteful in a rather common case... > > > > I'm not sure if skipping restarts on upgrade is worth the trouble. It > > should be quite simple to implement (e.g. by having the restart scriptlet > > check if the systemd target has been diverted to system-update.target), > > but restarting of services would most likely take only a small fraction > > of time required for the upgrade anyway. > > > > Maybe it should only restart the service if it's already running. In the > case of an upgrade it's a special target, right? > > Actually that's probably a good idea anyway. If I have stopped a service > (even if it's enabled) then it should not be restarted on upgrade. This is exactly what 'try-restart' does: it restarts the service only if it's running. Per the docs: try-restart PATTERN... Stop and then start one or more units specified on the command line if the units are running. This does nothing if units are not running. The current %systemd_postun_with_restart scriptlet uses try-restart: [adamw@adam koji ((koji-1.19.1))]$ rpm --eval "%systemd_postun_with_restart foo" if [ $1 -ge 1 ] && [ -x /usr/bin/systemctl ] ; then # Package upgrade, not uninstall /usr/bin/systemctl try-restart foo || : fi The Change page doesn't *specifically* state what scriptlets it's intended to replace, but I'd assume it would be that one. Thus I'd expect that this mechanism would also use try-restart. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: GCC10
One (the only) thing I've noticed so far about gcc-10 is that (sloppily) defined variables in header files that lack an extern qualifier and that don't have an explicit defn in a .c file are no longer 'common' or .comm but are now .global .bss and cause link errors due to duplicate definitions. This very well might be because I made a mistake in the way I built gcc-10. I'm not sure I have any way to know. If it's not a mistake on my part then this change has revealed a few bugs in the other applications that I work on. These bugs should be fixed of course, but it's something to be aware of when considering a major change like this, this late in the f32/rawhide development cycle. Almost certainly a lot of other things will have similar bugs. On Thu, Jan 2, 2020 at 10:12 AM Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/GCC10 > > == Summary == > Switch GCC in Fedora 32 to 10.x.y, rebuild all packages with it, or > optionally rebuild just some packages with it and rebuild all packages > only in Fedora 33. > > == Owner == > * Name: [[User:Jakub|Jakub Jelínek]] > * Email: ja...@redhat.com > > == Detailed Description == > > GCC 10 is currently in stage3, switching to stage4 in January, at > which point it will be in a prerelease state with only regression > bugfixes and documentation fixes allowed. The release will happen > probably in the middle of April. rpms will be built in early January, > but Jeff Law has been testing x86_64 Fedora test mass rebuilds with > GCC 10 snapshots for a while. > > > == Benefit to Fedora == > > See http://gcc.gnu.org/gcc-10/changes.html for the list of changes. > > == Scope == > * Proposal owners: > Prepare rpms for the new compiler, push them into rawhide, watch > voluntary rebuilds, fix bugs as they are reported, watch fallout from > mass rebuild. > > * Other developers: N/A (not a System Wide Change) > Adjust for what will be written in > https://gcc.gnu.org/gcc-10/porting_to.html , fix bugs in packages that > will show up after rebuild or report if there are bugs on the compiler > side. > > * Release engineering: Perform a mass rebuild, which will be needed > for the LTO System Wide change too. > > * Policies and guidelines: N/A (not a System Wide Change) > I don't think so, this is a usual system compiler update that is being > done every year. I think we have skipped GCC 4.2, so in Fedora this > is likely the 15th such System Wide change. > * Trademark approval: N/A (not needed for this Change) > > > == Upgrade/compatibility impact == > No impact > > == How To Test == > GCC has its own testsuite, which is run during the package build, plus > many other packages with automated tests also help to test the new > gcc. > > == User Experience == > Users will be able to see compiled code improvements and use the newly > added features. > Developers will notice a newer compiler, and might need to adjust > their codebases acording to http://gcc.gnu.org/gcc-10/porting_to.html, > or, if they detect a GCC bug, report it. > > == Dependencies == > libtool, annobin, gcc-python-plugin depend on exact gcc version, those > need to be rebuilt. > > == Contingency Plan == > If bugs are discovered, I'd appreciate help from the package owners in > preparing self-contained testcases to speed up analysis and fixing the > bugs. Don't have time to debug issues in 12000+ packages, especially > when in many cases it could be caused by undefined code in the > packages etc. I don't expect we'll have to fall back to the older > gcc, we've never had to do it in the past, > but worst case we can mass rebuild everything with older gcc again. > Jeff Law has performed test mass rebuild on x86_64. > > * Contingency mechanism: (What to do? Who will do it?) Revert to > older gcc, mass rebuild everything again > * Contingency deadline: Before release > * Blocks release? Yes > * Blocks product? No > > == Documentation == > http://gcc.gnu.org/gcc-10/ > > == Release Notes == > Fedora 32 comes with GCC 10.1 as primary compiler, see > http://gcc.gnu.org/gcc-10/changes.html for user visible changes in it. > > -- > Ben Cotton > He / Him / His > Fedora Program Manager > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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.fedoraproje
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
"John M. Harris Jr" writes: > On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote: >> Issuing the command once per week harms no one > > Based on what's actual in the Change proposal, this is not the case. > > Even if this goes through, in my opinion, it should only affect the GNOME > Spin, or perhaps even "all graphical" spins at most. No? This is extremely useful for cloud environments - maybe the most useful. It allows VM hosts to reclaim and reuse empty disk space; otherwise, the disk images just bloat to their maximum allowed size. Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Orphaning swingx
Hi, Due to the lack of time I have orhpaned swingx. If anyone wants to maintain it, please go ahead and pick it up. Please note that upstream is dead. swingx (and the rest of swinglabs projects) were lost as part of the dev.java.net shutdown years ago [1]. The last release of swingx on maven central was in 2010, 10 years ago [2]. [1] https://stackoverflow.com/questions/6818528/what-is-the-status-of-swinglabs-swingx-post-acquisition [2] https://mvnrepository.com/artifact/org.swinglabs/swingx Regards, Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
Kairui Song writes: > 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. > > /root/image/bin/bash > 4.8M. > /root/image/bin/sh > 4.8M. So it's not a direct comparison, but: $ du -sh /bin/bash /bin/dash 1.2M /bin/bash 132K /bin/dash This suggests to me that 1-3 MB could be reduced by using dash as the shell. (dash's library dependencies are also smaller since it drops requirements on libtinfo (200K) and libdl (36K); whether this matters I don't know.) Thanks, --Robbie signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: GCC10
On Thu, 2020-01-02 at 19:48 +, devel- requ...@lists.fedoraproject.org wrote: > Date: Thu, 2 Jan 2020 12:52:03 -0500 > From: Kaleb Keithley > Subject: Re: Fedora 32 System-Wide Change proposal: GCC10 > To: Development discussions related to Fedora > > Message-ID: > > Content-Type: multipart/alternative; > boundary="6bf9f6059b2bdac6" > > --6bf9f6059b2bdac6 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > One (the only) thing I've noticed so far about gcc-10 is that (sloppily) > defined variables in header files that lack an extern qualifier and that > don't have an explicit defn in a .c file are no longer 'common' or .comm > but are now .global .bss and cause link errors due to duplicate definitions= > . > > This very well might be because I made a mistake in the way I built gcc-10. > I'm not sure I have any way to know. > > If it's not a mistake on my part then this change has revealed a few bugs > in the other applications that I work on. > > These bugs should be fixed of course, but it's something to be aware of > when considering a major change like this, this late in the f32/rawhide > development cycle. Almost certainly a lot of other things will have similar > bugs. This is a known and desirable change in the compiler. GCC-10 defaults to -fno-common for C which is a change relative to gcc- 9 (C++ has been -fno-common for eons, possibly forever). You really should get your sources fixed to adhere to modern C standards. This affects ~450 packages in Fedora, openSUSE and other distributions. I have already reached out to ffesti (without a response :( to get an opt-out mechanism for redhat-rpm-config that would broken packages to opt-out of this behavior. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Restart services at end of rpm transaction
On Thu, Jan 02, 2020 at 09:39:38AM -0800, Adam Williamson wrote: > On Thu, 2020-01-02 at 11:18 -0600, Richard Shaw wrote: > > On Thu, Jan 2, 2020 at 10:14 AM Zbigniew Jędrzejewski-Szmek < > > zbys...@in.waw.pl> wrote: > > > > > On Thu, Jan 02, 2020 at 10:45:07AM -0500, Neal Gompa wrote: > > > > On Thu, Jan 2, 2020 at 10:11 AM Ben Cotton wrote: > > > > Even with this proposal, how do we deal with system upgrades? In the > > > > system upgrade case, we don't really want these restarts to run, > > > > because the system will be rebooted anyway... These kinds of questions > > > > are why I didn't propose porting over what we did in OpenMandriva to > > > > Fedora. It's rather wasteful in a rather common case... > > > > > > I'm not sure if skipping restarts on upgrade is worth the trouble. It > > > should be quite simple to implement (e.g. by having the restart scriptlet > > > check if the systemd target has been diverted to system-update.target), > > > but restarting of services would most likely take only a small fraction > > > of time required for the upgrade anyway. > > > > > > > Maybe it should only restart the service if it's already running. In the > > case of an upgrade it's a special target, right? > > > > Actually that's probably a good idea anyway. If I have stopped a service > > (even if it's enabled) then it should not be restarted on upgrade. > > This is exactly what 'try-restart' does: it restarts the service only > if it's running. Per the docs: > >try-restart PATTERN... >Stop and then start one or more units specified on the command > line if the units are running. This does >nothing if units are not running. > > The current %systemd_postun_with_restart scriptlet uses try-restart: > > [adamw@adam koji ((koji-1.19.1))]$ rpm --eval "%systemd_postun_with_restart > foo" > > > if [ $1 -ge 1 ] && [ -x /usr/bin/systemctl ] ; then > # Package upgrade, not uninstall > /usr/bin/systemctl try-restart foo || : > fi > > The Change page doesn't *specifically* state what scriptlets > it's intended to replace, but I'd assume it would be that one. Thus I'd > expect that this mechanism would also use try-restart. Yes, exactly. Thank you for the very nice summary. More generally, the goal is to do the exact same restarts that are done now, but at a different point in the transaction and from a different call site. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
On Thu, Jan 02, 2020 at 03:29:26PM -0500, Robbie Harwood wrote: > Kairui Song writes: > > > 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. > > > > /root/image/bin/bash > > 4.8M. > > /root/image/bin/sh > > 4.8M. > > So it's not a direct comparison, but: > > $ du -sh /bin/bash /bin/dash > 1.2M /bin/bash > 132K /bin/dash > > This suggests to me that 1-3 MB could be reduced by using dash as the > shell. (dash's library dependencies are also smaller since it drops > requirements on libtinfo (200K) and libdl (36K); whether this matters I > don't know.) dash doesn't support various bash extensions and syntaxes. The problem is that many scripts which use #!/bin/sh really require #!/bin/bash. So after switching to dash as the provider of /bin/sh various scripts would suddenly behave differently, and those bugs would only be detected at runtime. Debian went through a long process of switching to dash as the default init shell and fixing various scripts to remove bashisms so things would run on dash (or any other /bin/sh). This was way more work than anyone excepted and took a long time. IMO the gain of 1 MB that we would get is not nearly enough to offset the work required and the destabilization. (In Debian the motivation was speed, rather than installation footprint. So that work was mostly wasted because of the switch from sysvinit to systemd and ensuing avoidance of shell during boot. Instead of trying to switch shells, we should instead try to avoid shell in boot as much as possible.) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: glusterfs-7.1 update stuck in pending->testing for 10 days
On Thu, Jan 02, 2020 at 09:14:30AM -0500, Kaleb Keithley wrote: > related to bodhi having gone down? > > Can someone kick it please? I would if I could. This is due to the ongoing koji issues. Hopefully bodhi folks are going to look at it tomorrow morning and we can at least get updates flowing again. I'd like to thank everyone for their patience on this, it's been very frustrating for me personally. ;( I'm sure we will find a fix as more folks come back from holidays and dig into this issue. kevin signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
On Thu, 2020-01-02 at 22:59 +, Zbigniew Jędrzejewski-Szmek wrote: > (In Debian the motivation was speed, rather than installation footprint. > So that work was mostly wasted because of the switch from sysvinit to systemd > and ensuing avoidance of shell during boot. Instead of trying to switch > shells, we should instead try to avoid shell in boot as much as possible.) this may be tricky since dracut is just a giant ball of shell scripts that no-one likes to touch...:P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: peek package
On Wednesday, January 1, 2020 7:34:27 PM MST Leigh Scott wrote: > > Why we should drop such useful app just because it doesn't work on > > Cinnamon? It works on GNOME without ffpmeg and rpm fusion repo, see > > screenshot [1]. > > > Please prevent your useless app from displaying in cinnamon menu, I'm sure > Mate, XFCE and LXDE would also like it removed from their menus as well. > Add this to it's desktop file! > > 'OnlyShowIn=Gnome' Agreed, I'd like to see it removed from Plasma's menu by default as well. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Thursday, January 2, 2020 12:47:37 PM MST Robbie Harwood wrote: > "John M. Harris Jr" writes: > > On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote: > >> Issuing the command once per week harms no one > > > > Based on what's actual in the Change proposal, this is not the case. > > > > Even if this goes through, in my opinion, it should only affect the GNOME > > Spin, or perhaps even "all graphical" spins at most. > > No? This is extremely useful for cloud environments - maybe the most > useful. It allows VM hosts to reclaim and reuse empty disk space; > otherwise, the disk images just bloat to their maximum allowed size. > > Thanks, > --Robbie It's possible this would be useful in some "cloud" environments. In that case, those "cloud" hosting providers should put it in their default image. -- John M. Harris, Jr. Splentity ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Status of bodhi
There was a note recently in one the the kernel packages about bodhi being a tad temperamental recently and not pushing updates out. Anyone knows what's going on with that? Is the fix on the horizon? -- Bojan___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Status of bodhi
Seems like this issue https://pagure.io/fedora-infrastructure/issue/8477 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Fedora 32 System-Wide Change proposal: Enable fstrim.timer by default
On Thu, Jan 2, 2020 at 2:48 PM Robbie Harwood wrote: > > "John M. Harris Jr" writes: > > > On Friday, December 20, 2019 10:59:52 AM MST Chris Murphy wrote: > >> Issuing the command once per week harms no one > > > > Based on what's actual in the Change proposal, this is not the case. > > > > Even if this goes through, in my opinion, it should only affect the GNOME > > Spin, or perhaps even "all graphical" spins at most. > > No? This is extremely useful for cloud environments - maybe the most > useful. It allows VM hosts to reclaim and reuse empty disk space; > otherwise, the disk images just bloat to their maximum allowed size. > > Thanks, > --Robbie Its most useful for the cloud *providers*, not the cloud clients. For the clients, getting the AWS space pre-allocated form EBS is often a notable performance improvement, and restoring it to AWS saves AWS resources. Not the client system performance. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > > 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/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. > > All systemd binaries will mostly link to the same libraries (because > they link to a private shared library, which links to various other > shared libraries). So this "20M" will be repeated over and over, but > it's the same dependencies. > > While we'd all prefer for this to be smaller, 20M should is actually > not that much... > > > 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) > > This is slightly misleading. Code was moved from individual binaries > to libsystemd-shared-nnn.so, so if you look at the deps of just a single > binary, you'll see many more deps (because libsystemd-shared-nnn.so has > more deps). But the total number of deps when summed over all binaries > grew much less. A more useful measure would be the size with deps summed > over all systemd binaries that are installed into your image in v219 and > v243. > I vaguely remember the size increased before due to linking with libidn2 previously, so those libraries contribute a lot. Does every systemd binary depend on all libraries? Or each of the systemd binary only depends on those libs when really needed? Thanks Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
On 01/03/20 at 11:45am, Dave Young wrote: > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > > > 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/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. > > > > All systemd binaries will mostly link to the same libraries (because > > they link to a private shared library, which links to various other > > shared libraries). So this "20M" will be repeated over and over, but > > it's the same dependencies. > > > > While we'd all prefer for this to be smaller, 20M should is actually > > not that much... > > > > > 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) > > > > This is slightly misleading. Code was moved from individual binaries > > to libsystemd-shared-nnn.so, so if you look at the deps of just a single > > binary, you'll see many more deps (because libsystemd-shared-nnn.so has > > more deps). But the total number of deps when summed over all binaries > > grew much less. A more useful measure would be the size with deps summed > > over all systemd binaries that are installed into your image in v219 and > > v243. > > > > I vaguely remember the size increased before due to linking with libidn2 > previously, so those libraries contribute a lot. > > Does every systemd binary depend on all libraries? Or each of the > systemd binary only depends on those libs when really needed? For example if I do not need journalctl, then I can drop journalctl and those libraries specific for journalctl? > > Thanks > Dave ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
On Thu, Jan 2, 2020 at 5:04 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > > 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/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. > > All systemd binaries will mostly link to the same libraries (because > they link to a private shared library, which links to various other > shared libraries). So this "20M" will be repeated over and over, but > it's the same dependencies. > > While we'd all prefer for this to be smaller, 20M should is actually > not that much... > > > 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) > > This is slightly misleading. Code was moved from individual binaries > to libsystemd-shared-nnn.so, so if you look at the deps of just a single > binary, you'll see many more deps (because libsystemd-shared-nnn.so has > more deps). But the total number of deps when summed over all binaries > grew much less. A more useful measure would be the size with deps summed > over all systemd binaries that are installed into your image in v219 and > v243. > Yes, you are right. I use following method to measure the size of the binary together with the library it used: Just call dracut-install to install a binary into an empty folder as new root, that tool can also take care of resolve and installing the libraries. The result it like this: With systemd V243: [root@localhost test]# for i in /usr/bin/systemd-*; do /usr/lib/dracut/dracut-install -l -D $(pwd) $i; done [root@localhost test]# for i in /lib/systemd/systemd-*; do /usr/lib/dracut/dracut-install -l -D $(pwd) $i; done [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /lib/systemd/systemd [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/journalctl [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/loginctl [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/systemctl [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/udevadm [root@localhost test]# du -hs . 34M . With V219: [root@localhost test]# for i in /usr/bin/systemd-*; do /usr/lib/dracut/dracut-install -l -D $(pwd) $i; done [root@localhost test]# for i in /usr/lib/systemd/systemd-*; do /usr/lib/dracut/dracut-install -l -D $(pwd) $i; done [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/lib/systemd/systemd [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/journalctl [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/loginctl [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/systemctl [root@localhost test]# /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/udevadm [root@localhost test]# du -hs . 33M . So indeed it didn't grow in total. But kdump's initramfs only need a subset of all binaries, so if I only install the files needed: With V243: [root@localhost test]# for i in systemd systemd-coredump systemd-cgroups-agent systemd-shutdown systemd-reply-password systemd-fsck systemd-udevd systemd-journald systemd-sysctl systemd-modules-load systemd-vconsole-setup; do /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/lib/systemd/$i; done [root@localhost test]# [root@localhost test]# for i in journalctl systemctl udevadm systemd-run systemd-escape systemd-cgls systemd-tmpfiles; do /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/$i; done [root@localhost test]# du -hs . 24M . With V219: [root@localhost test]# for i in systemd systemd-coredump systemd-cgroups-agent systemd-shutdown systemd-reply-password systemd-fsck systemd-udevd systemd-journald systemd-sysctl systemd-modules-load systemd-vconsole-setup; do /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/lib/systemd/$i; done [root@localhost test]# for i in journalctl systemctl udevadm systemd-run systemd-escape systemd-cgls systemd-tmpfiles; do /usr/lib/dracut/dracut-install -l -D $(pwd) /usr/bin/$i; done [root@localhost test]# du -hs . 12M . That did grow a lot. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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_guid
Re: Status of bodhi
OK, thanks for the pointer. -- Bojan___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Re: Minimize systemd for kdump's initramfs
On Fri, Jan 03, 2020 at 11:48:53AM +0800, Dave Young wrote: > On 01/03/20 at 11:45am, Dave Young wrote: > > On 01/02/20 at 09:02am, Zbigniew Jędrzejewski-Szmek wrote: > > > On Thu, Jan 02, 2020 at 12:21:26AM +0800, Kairui Song wrote: > > > > 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/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. > > > > > > All systemd binaries will mostly link to the same libraries (because > > > they link to a private shared library, which links to various other > > > shared libraries). So this "20M" will be repeated over and over, but > > > it's the same dependencies. > > > > > > While we'd all prefer for this to be smaller, 20M should is actually > > > not that much... > > > > > > > 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) > > > > > > This is slightly misleading. Code was moved from individual binaries > > > to libsystemd-shared-nnn.so, so if you look at the deps of just a single > > > binary, you'll see many more deps (because libsystemd-shared-nnn.so has > > > more deps). But the total number of deps when summed over all binaries > > > grew much less. A more useful measure would be the size with deps summed > > > over all systemd binaries that are installed into your image in v219 and > > > v243. > > > > > > > I vaguely remember the size increased before due to linking with libidn2 > > previously, so those libraries contribute a lot. > > > > Does every systemd binary depend on all libraries? Or each of the > > systemd binary only depends on those libs when really needed? > > For example if I do not need journalctl, then I can drop journalctl and > those libraries specific for journalctl? It's using standard shared object linking, so yeah, for anything which libsystemd-shared-nnn.so links to, "every systemd binary depend[s] on all libraries", in the sense that the runtime linker will fail to start the executable if any of the libraries are missing. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
