[opensuse-releaseteam] Bug 1133594 - Deadline for Leap 15.1
Hey, I am trying to fix: https://bugzilla.suse.com/show_bug.cgi?id=1133594 Which (also) appears on Leap 15.1, which I would like to fix before release. If I have understood Ludwig correctly, Leap 15.1 inherits the package from SLE-15-SP1:GA. I can't open SRs against it anymore. I have opened one against SLE-15-SP1:Update: https://build.suse.de/request/show/192058 Is this fine or do I need to do something additionally? Simon -- 6DFE EAC6 CB38 1F78 5FDA 91F3 AC64 34A6 41FC 10F5
Simon Schricker schrieb:
I am trying to fix: https://bugzilla.suse.com/show_bug.cgi?id=1133594
Which (also) appears on Leap 15.1, which I would like to fix before release.
If I have understood Ludwig correctly, Leap 15.1 inherits the package from SLE-15-SP1:GA. I can't open SRs against it anymore. I have opened one against SLE-15-SP1:Update: https://build.suse.de/request/show/192058
Is this fine or do I need to do something additionally?
The maintenance update will be released for Leap 15.1 when the update for SLE gets released. Looking at the package I see it writes to /sys in %posttrans. Not sure what that causes exactly but most certainly you don't want that it buildroots, container builds or installation environments etc. So should rather be done on service start up or system boot. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-releaseteam+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-releaseteam+owner@opensuse.org
On Mon, 2019-05-13 at 15:55 +0200, Ludwig Nussel wrote:
Looking at the package I see it writes to /sys in %posttrans. Not sure what that causes exactly but most certainly you don't want that it buildroots, container builds or installation environments etc. So should rather be done on service start up or system boot.
It uses the sysfs interface of the kernel module to recheck (discover) nvme devices provided over Network via Fibre Channel. This will then trigger udev-events, which are handled by systemd-services and nvme (the user-space binary), both shipped by the nvme-cli package. Which means if we upgrade the nvme-cli packages it makes sense to retrigger the udev-events, because the handling via the systemd- services and nvme could have changed. The nvmefc-boot-connections.service, which does the same at boot, is inactive after booting, so the package upgrade won't restart it. The echo in the %posttrans section seemed to be the simplest solution, but I am open for improvements. Cheers Simon -- 6DFE EAC6 CB38 1F78 5FDA 91F3 AC64 34A6 41FC 10F5
participants (2)
-
Ludwig Nussel -
Simon Schricker