[Bug 1118740] New: Review Request: fakesystemd - Minimal docker-specific package to satisfy systemd Provides
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Bug ID: 1118740 Summary: Review Request: fakesystemd - Minimal docker-specific package to satisfy systemd Provides Product: Fedora Version: rawhide Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: vpavlin@redhat.com QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org
Spec URL: http://vpavlin.fedorapeople.org/fakesystemd/fakesystemd.spec SRPM URL: http://vpavlin.fedorapeople.org/fakesystemd/fakesystemd-1-15.fc20.src.rpm
Description: fakesystemd is a minimal Docker-specific package to satisfy systemd Provides: without installing systemd in Docker images. It is intended strictly for use in Docker images/containers. It doesn't provide any functionality from systemd package - it only contains few important directories and files. fakesystemd is definitely not applicable for full bootable operation system.
If possible, it shouldn't be shipped in primary repo and should be available only for building (Docker) images.
To install real systemd in the image you need to run yum swap command in this form:
yum swap -- remove fakesystemd -- install systemd systemd-libs
Fedora Account System Username: vpavlin
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Matthew Miller mattdm@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mattdm@redhat.com
--- Comment #1 from Matthew Miller mattdm@redhat.com ---
If possible, it shouldn't be shipped in primary repo and should be available only for building (Docker) images.
That's not currently possible. Maybe in the future. We'll need to do some sanity checking to make sure no installs pull this in instead of the real systemd by accident.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Matthew Miller mattdm@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|nobody@fedoraproject.org |mattdm@redhat.com
--- Comment #2 from Matthew Miller mattdm@redhat.com --- I've got some pendantic things to clear up first.
1. Please make the summary shorter and the description longer, including a gigantic warning not to install on a real system. And the summary shouldn't end in a period. (I told you this was pedantic -- sorry!)
2. License says "GPL+", but no actual license text is included. Since this is by nature minimal, what about using a much simpler license (like MIT -- maybe https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT#Modern_Style_w...) and including the text directly in macros.systemd?
3. Since it conflicts with systemd, needs an explicit "Conflicts: systemd"
4. Copy in %prep stage is unnecessary (and in fact since you refer to %{SOURCE0} directly later, it's not even doing anything
5. In %install stage, I think the big mkdir would be much easier to read and maintain in a loop, like:
for dir in systemd/system systemd/user tmpfiles.d sysctl.d modules-load.d binfmt.d udev/rules.d do mkdir -p %{buildroot}%{_sysconfdir}/${dir} done
for dir in system-generators user-generators system-preset user-preset system-shutdown system-sleep catalog ntp-units.d do mkdir -p %{buildroot}%{_prefix}/lib/systemd/${dir} done
for dir in tmpfiles.d sysctl.d sysctl.d modules-load.d binfmt.d do mkdir -p %{buildroot}%{_prefix}/lib/${dir} done
mkdir -p %{buildroot}%{_datadir}/systemd mkdir -p %{buildroot}%{_datadir}/pkgconfig mkdir -p %{buildroot}%{_localstatedir}/lib/systemd/catalog
That's your call, but I think we'll be happier later. :)
An alternate approach would be to make a source tarball containing all of these directories (along with the macro file), and just unpack it.
6. Can we get away with making this noarch?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #3 from Václav Pavlín vpavlin@redhat.com --- Thanks very much for your input, Matt!
I've updated spec and macro files to follow your suggestions.
See http://vpavlin.fedorapeople.org/fakesystemd/
Regards, Vaclav
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Michal Sekletar msekleta@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |msekleta@redhat.com
--- Comment #4 from Michal Sekletar msekleta@redhat.com --- (In reply to Matthew Miller from comment #1)
If possible, it shouldn't be shipped in primary repo and should be available only for building (Docker) images.
That's not currently possible. Maybe in the future. We'll need to do some sanity checking to make sure no installs pull this in instead of the real systemd by accident.
I'd like to know more about how exactly are we going to enforce that no one accidentally installs fakesystemd.
I want to start working on minimal systemd to be used for multi app containers. Very similar to systemd-container we have in RHEL7. It will able to boot up little else than container, hence we don't want users to install it on real machine by mistake.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #5 from Matthew Miller mattdm@redhat.com --- So, the theory is: put systemd in the @core group so that it's picked by default, not pulled in by deps. Once it's there, the Conflicts will keep anyone from adding fakesystemd by accident, and the protected packages feature of yum (and now DNF) will keep real systemd from being removed.
That's the theory, at least. :)
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #6 from Václav Pavlín vpavlin@redhat.com --- FYI, systemd is in @core since F14 (see https://git.fedorahosted.org/cgit/comps.git/commit/?id=4e79f60c30b1cb6db55b1...)
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Matthew Miller mattdm@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-review+
--- Comment #7 from Matthew Miller mattdm@redhat.com --- Looks good. Conflicts with systemd on my laptop and does not install, so that's good. :)
Review passed. Obviously contains directories owned by other packages, but that's kind of the point..
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Václav Pavlín vpavlin@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-cvs?
--- Comment #8 from Václav Pavlín vpavlin@redhat.com --- New Package SCM Request ======================= Package Name: fakesystemd Short Description: Docker-specific package to simulate systemd presence in system Upstream URL: None Owners: vpavlin Branches: f20 f21 InitialCC: vpavlin
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #9 from Jon Ciesla limburgher@gmail.com --- WARNING: Upstream URL seems to be invalid
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Jon Ciesla limburgher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-cvs? |
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #10 from Matthew Miller mattdm@redhat.com --- (In reply to Jon Ciesla from comment #9)
WARNING: Upstream URL seems to be invalid
Yes, there is no upstream here (or, really, source); this is a stub package.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Václav Pavlín vpavlin@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-cvs?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #11 from Jon Ciesla limburgher@gmail.com --- Then it would seem that the upstream is Fedora, you could use http://fedoraproject.org or something.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Jon Ciesla limburgher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-cvs? |
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Václav Pavlín vpavlin@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |fedora-cvs?
--- Comment #12 from Václav Pavlín vpavlin@redhat.com --- New Package SCM Request ======================= Package Name: fakesystemd Short Description: Docker-specific package to simulate systemd presence in system Upstream URL: http://fedoraproject.org Owners: vpavlin Branches: f20 f21 InitialCC: vpavlin
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Jon Ciesla limburgher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-cvs? |fedora-cvs+
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #13 from Jon Ciesla limburgher@gmail.com --- Git done (by process-git-requests).
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Tobias Florek me@ibotty.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |me@ibotty.net
--- Comment #14 from Tobias Florek me@ibotty.net --- What's the status? Shouldn't that package show up at one point?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #15 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- No, please kill the package instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #16 from Tobias Florek me@ibotty.net --- Sorry, I don't understand what you mean.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #17 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- Afaik, this package was causing more problems then it was solving, and that's why it was never built and submitted as an update. If that is true, it would be best to clearly kill the package (make it a dead package).
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Jan Pazdziora jpazdziora@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jpazdziora@redhat.com, | |vpavlin@redhat.com Flags| |needinfo?(vpavlin@redhat.co | |m)
--- Comment #18 from Jan Pazdziora jpazdziora@redhat.com --- Václav,
can this bugzilla be closed and https://github.com/fedora-cloud/docker-brew-fedora/blob/master/fedora-docker... purged since I believe fakesystemd was made obsolete by systemd-container which was made obsolete by recent changes in systemd?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Yaakov Selkowitz yselkowi@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yselkowi@redhat.com
--- Comment #19 from Yaakov Selkowitz yselkowi@redhat.com --- (In reply to Zbigniew Jędrzejewski-Szmek from comment #17)
Afaik, this package was causing more problems then it was solving, and that's why it was never built and submitted as an update. If that is true, it would be best to clearly kill the package (make it a dead package).
Could you specify? I believe this would still be useful as systemd and its dependencies still take up a lot of space (~16%) in a docker base image for seemingly no reason.
As for how to handle the Conflicts, I think we can use coreutils-single as a model. Based on that, systemd should:
Conflicts: fakesystemd Obsoletes: fakesystemd
and then fakesystemd should:
Provides: systemd
If that is done, does that solve whatever problems there were?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Yaakov Selkowitz yselkowi@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1323209 (base-minimization)
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1323209 [Bug 1323209] [TRACKER] base minimization effort
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Harald Hoyer harald@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |harald@redhat.com
--- Comment #20 from Harald Hoyer harald@redhat.com --- (In reply to Yaakov Selkowitz from comment #19)
(In reply to Zbigniew Jędrzejewski-Szmek from comment #17)
Afaik, this package was causing more problems then it was solving, and that's why it was never built and submitted as an update. If that is true, it would be best to clearly kill the package (make it a dead package).
Could you specify? I believe this would still be useful as systemd and its dependencies still take up a lot of space (~16%) in a docker base image for seemingly no reason.
As for how to handle the Conflicts, I think we can use coreutils-single as a model. Based on that, systemd should:
Conflicts: fakesystemd Obsoletes: fakesystemd
and then fakesystemd should:
Provides: systemd
If that is done, does that solve whatever problems there were?
I would rather go down the road and create an opt-in scheme, where packages remove the %systemd_requires macro, if the package is able to run without systemd.
The systemd_{post,preun} macros don't fail, if anything goes wrong.
E.g. packages, which rely on %sysusers_create would probably not work.
Or if packages rely on a systemd API/ABI/functionality.
Please let it be an opt-in, rather than a magic fakesystemd package, where support tickets will be opened, because the package doesn't work as advertised, because it really needs a functional systemd.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #21 from Harald Hoyer harald@redhat.com --- (In reply to Harald Hoyer from comment #20)
(In reply to Yaakov Selkowitz from comment #19)
(In reply to Zbigniew Jędrzejewski-Szmek from comment #17)
Afaik, this package was causing more problems then it was solving, and that's why it was never built and submitted as an update. If that is true, it would be best to clearly kill the package (make it a dead package).
Could you specify? I believe this would still be useful as systemd and its dependencies still take up a lot of space (~16%) in a docker base image for seemingly no reason.
As for how to handle the Conflicts, I think we can use coreutils-single as a model. Based on that, systemd should:
Conflicts: fakesystemd Obsoletes: fakesystemd
and then fakesystemd should:
Provides: systemd
If that is done, does that solve whatever problems there were?
I would rather go down the road and create an opt-in scheme, where packages remove the %systemd_requires macro, if the package is able to run without systemd.
Requires(post): systemd Requires(preun): systemd Requires(postun): systemd
would become
Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd
The systemd_{post,preun} macros don't fail, if anything goes wrong.
E.g. packages, which rely on %sysusers_create would probably not work.
Or if packages rely on a systemd API/ABI/functionality.
Please let it be an opt-in, rather than a magic fakesystemd package, where support tickets will be opened, because the package doesn't work as advertised, because it really needs a functional systemd.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #22 from Yaakov Selkowitz yselkowi@redhat.com --- (In reply to Harald Hoyer from comment #21)
(In reply to Harald Hoyer from comment #20)
I would rather go down the road and create an opt-in scheme, where packages remove the %systemd_requires macro, if the package is able to run without systemd.
Requires(post): systemd Requires(preun): systemd Requires(postun): systemd
would become
Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd
That may very well be a better approach overall, but I'm not sure about the Recommends:, I think Suggests: or nothing at all would make more sense in at least some cases.
What that does require is for systemd to handle all previously installed (but deferred) presets in %post [ $1 == 1 ]. How exactly?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(vpavlin@redhat.co | |m) |
--- Comment #23 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl ---
What that does require is for systemd to handle all previously installed (but deferred) presets in %post [ $1 == 1 ]. How exactly?
We could add 'if[ $1 == 1 ]; then systemctl preset-all; fi', which would call presets for all packages that were installed previously. Unfortunately it would also undo any enablement/disablement that was done previously. We don't keep any state that would tell us for which packages systemd preset should be called, instead every package does the call itself on initial install.
But it'd be really unexpected to have a normal system without systemd installed in the initial transaction, so maybe that's OK. We'd have to document the fact that initial installation of systemd removes unit enablement configuration.
We already call 'udevadm hwdb --update' and 'journalctl --update-catalog' and 'systemd-tmpfiles --create' in systemd %post, so other calls to systemd functionality that happen in package scriptlets should be covered.
(In reply to Yaakov Selkowitz from comment #22)
Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd
I'd rather turn this into another macro (%systemd_ordering ?).
That may very well be a better approach overall, but I'm not sure about the Recommends:, I think Suggests: or nothing at all would make more sense in at least some cases.
Either would work. Recommends is likely to be ignored when creating a minimal image anyway. But Recommends has the advantage that systemd would be pulled in when creating a chroot with dnf.
PS. I'll remove needinfo, because Vaclav retired the package in pkgdb last year. Let's keep the bug open for discussion.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #24 from Harald Hoyer harald@redhat.com --- I would not support to install systemd in post. Either it's there from the beginning or not.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Harald Hoyer harald@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|harald@redhat.com |
--- Comment #24 from Harald Hoyer harald@redhat.com --- I would not support to install systemd in post. Either it's there from the beginning or not.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #25 from Harald Hoyer harald@redhat.com --- (In reply to Zbigniew Jędrzejewski-Szmek from comment #23)
Recommends: systemd OrderWithRequires(post): systemd OrderWithRequires(preun): systemd OrderWithRequires(postun): systemd
I'd rather turn this into another macro (%systemd_ordering ?).
%systemd_recommends could hold all of the above.
Another approach would be:
Requires: systemd %systemd_ordering
and
Recommends: systemd %systemd_ordering
because the ordering works in both scenarios.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #26 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- I think the macro should contain the whole thing, to make it as simple to use as possible. But that's a detail that can be worked out later.
The changes required are trivial to implement, just a few lines in systemd.macros. We can just add it and allow people to use it, but the FPC should probably update the guidelines to mention the new macro.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #27 from Yaakov Selkowitz yselkowi@redhat.com --- (In reply to Zbigniew Jędrzejewski-Szmek from comment #26)
I think the macro should contain the whole thing, to make it as simple to use as possible. But that's a detail that can be worked out later.
I'm still not convinced of the need for even Recommends: systemd here. Compare the desktop-database, mimeinfo, and icon-cache scriptlets, which explicitly do NOT mandate any Requires:. I believe this is the same: if systemd is already present, then the scriptlets will succeed, otherwise they are ignored. Only packages which are completely useless outside of systemd should then use %systemd_requires.
The changes required are trivial to implement, just a few lines in systemd.macros. We can just add it and allow people to use it, but the FPC should probably update the guidelines to mention the new macro.
Yes, this should go through FPC once we have some agreement on the above.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Yaakov Selkowitz yselkowi@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(zbyszek@in.waw.pl | |)
--- Comment #28 from Yaakov Selkowitz yselkowi@redhat.com --- What more is needed to move this forward?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Yaakov Selkowitz yselkowi@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hhoyer@redhat.com Flags| |needinfo?(hhoyer@redhat.com | |)
--- Comment #29 from Yaakov Selkowitz yselkowi@redhat.com --- Harald, can we get this going?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #30 from Jan Pazdziora jpazdziora@redhat.com --- Is the a plan in place to change the Fedora base image to drop systemd and carry fakesystemd?
If there is one, could some links to where this change is being proposed and discussed be added here?
If there is not and base images will always carry systemd, I wonder what the purpose and expected use of fakesystemd would be. The images would already have systemd in them, and even if layered images replaced it with fakesystemd, users would still have to get the base image which had it, killing the whole purpose.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #31 from Yaakov Selkowitz yselkowi@redhat.com --- (In reply to Jan Pazdziora from comment #30)
Is the a plan in place to change the Fedora base image to drop systemd and carry fakesystemd?
No, the plan currently being discussed is for the Docker base image to simply drop systemd by making sure nothing pulls it in as a dependency unless it *really* needs it.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #32 from Jan Pazdziora jpazdziora@redhat.com --- (In reply to Yaakov Selkowitz from comment #31)
No, the plan currently being discussed is for the Docker base image to simply drop systemd by making sure nothing pulls it in as a dependency unless it *really* needs it.
Could you please add link to where this discussion is taking place?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #33 from Yaakov Selkowitz yselkowi@redhat.com --- (In reply to Jan Pazdziora from comment #30)
Is the a plan in place to change the Fedora base image to drop systemd and carry fakesystemd?
No; see above starting at comment 20 for the current plan.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Brendan Conoboy blc@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blc@redhat.com Flags|needinfo?(hhoyer@redhat.com |needinfo?(harald@redhat.com |) |)
--- Comment #34 from Brendan Conoboy blc@redhat.com --- Updating needinfo with Harald's correct email address.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Harald Hoyer harald@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(zbyszek@in.waw.pl | |) | |needinfo?(harald@redhat.com | |) |
--- Comment #35 from Harald Hoyer harald@redhat.com --- https://github.com/systemd/systemd/pull/3776
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Harald Hoyer harald@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Doc Type|Bug Fix |Enhancement
--- Comment #36 from Harald Hoyer harald@redhat.com --- Maybe we can add a check in the %pre macro of systemd, which recognizes already populated /lib/systemd/system or /usr/lib/tmpfiles.d and prints out a big fat warning on first installation.
So, here is my recommendation for the package guidelines:
If a package is suitable for an alternative init system or e.g. container image, and does not require any of the systemd mechanisms e.g. to install UID, GID, or tmpfiles, it can choose to use the %systemd_ordering macro instead of the %systemd_requires macro. Adding "Recommends: systemd" or "Suggests: systemd" is optional.
Note: installing systemd afterwards in a separate rpm transaction does not produce the same result.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Harald Hoyer harald@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Review Request: fakesystemd |Remove the hard dependency |- Minimal docker-specific |on systemd for packages, |package to satisfy systemd |which make use of systemd |Provides |rpm macros
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #37 from Yaakov Selkowitz yselkowi@redhat.com --- Policy guideline discussion: https://fedorahosted.org/fpc/ticket/644
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
--- Comment #38 from Yaakov Selkowitz yselkowi@redhat.com --- (In reply to Harald Hoyer from comment #36)
Note: installing systemd afterwards in a separate rpm transaction does not produce the same result.
What about the proposal in comment 23 wrt handling pre-installed presets in %post if [ $1 == 1 ]?
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |POST
--- Comment #39 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- OK, let's see how that works out in real life.
Implemented in http://pkgs.fedoraproject.org/cgit/rpms/systemd.git/commit/?id=46083abe1a4de..., but I didn't rebuild.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|POST |CLOSED Fixed In Version| |systemd-231-2.fc25.x86_64 Resolution|--- |RAWHIDE Last Closed| |2016-07-26 22:47:28
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Adam Williamson awilliam@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |ASSIGNED CC| |awilliam@redhat.com Resolution|RAWHIDE |--- Keywords| |Reopened
--- Comment #40 from Adam Williamson awilliam@redhat.com --- Sorry, but it...doesn't work well. At all. preset-all doesn't really work right.
https://bugzilla.redhat.com/show_bug.cgi?id=1363858
I am going to revert the change in the systemd package for now since it broke tty1 and thus broke all openQA tests.
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Adam Williamson awilliam@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.redhat.com | |/show_bug.cgi?id=1363858
https://bugzilla.redhat.com/show_bug.cgi?id=1118740
Adam Williamson awilliam@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution|--- |RAWHIDE Last Closed|2016-07-26 22:47:28 |2018-11-08 19:43:17
--- Comment #41 from Adam Williamson awilliam@redhat.com --- I've just reapplied the change from #c23 in Rawhide, because it should help with https://bugzilla.redhat.com/show_bug.cgi?id=1647172 . So we can close this as FIXED again, I guess! Even though I don't really remember what the change was even supposed to help with...
preset-all got fixed up upstream, so the problems from 1363858 should not happen again.
package-review@lists.fedoraproject.org
-
bugzilla＠redhat.com -
Red Hat Bugzilla