Bug 1330493 - [Intel] Update memkind RPM to upstream 1.1.0
Summary: [Intel] Update memkind RPM to upstream 1.1.0
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: memkind
Version: epel7
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Rafael Aquini
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1210910
TreeView+ depends on / blocked
 
Reported: 2016-04-26 11:03 UTC by lukasz.anaczkowski
Modified: 2016-07-11 12:05 UTC (History)
10 users (show)

Fixed In Version: memkind-1.1.0-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-05 06:19:16 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description lukasz.anaczkowski 2016-04-26 11:03:06 UTC
Description of problem:
EPEL memkind does not start memkind service by default after package installation. According to
https://fedoraproject.org/wiki/Packaging:DefaultServices?rd=Starting_services_by_default
there is no strong argument against that. If no other objections, please adjust memkind EPEL package such that service is started by default after package installation.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Rafael Aquini 2016-04-26 14:35:35 UTC
Would you mind checking if the following scracth build does fit the request?

https://kojipkgs.fedoraproject.org//work/tasks/821/13810821/memkind-1.0.0-2.fc25.x86_64.rpm

Thanks in advance!
-- Rafael

Comment 2 Rafael Aquini 2016-04-26 14:53:13 UTC
Just a remainder: differently from SysV initscripts, services are not anymore "started" on RPM install time but just set to be loaded by default, under systemd -- 

https://fedoraproject.org/wiki/Packaging:Systemd#Why_don.27t_we....



For automatic activation, you'll probably going to need an udev rule:
https://fedoraproject.org/wiki/Packaging:Systemd#Hardware_activation

Comment 3 lukasz.anaczkowski 2016-04-26 17:37:50 UTC
(In reply to Rafael Aquini from comment #1)
> Would you mind checking if the following scracth build does fit the request?
> 
> https://kojipkgs.fedoraproject.org//work/tasks/821/13810821/memkind-1.0.0-2.
> fc25.x86_64.rpm
> 
> Thanks in advance!
> -- Rafael

Of course! Thanks for such a prompt response!

Comment 4 lukasz.anaczkowski 2016-04-28 10:34:39 UTC
Hi Rafael,

Here's the update:

1) 1.0.0 package (both 1 & 2 release) does not have required libmemkind.so. It's a fixed bug in memkind src:
commit fe61f4638cd9ca41fff13aee920084470e451071
Author: akoziej <artur.koziej>
Date:   Fri Feb 19 17:39:31 2016 +0100

    Fix missing libmemkind.so file in memkind RPM.
    Remove libmemkind.so from memkind-devel.

Could you pull this in?

2) after RPM installation, memkind service does not start, nor is enabled (i.e. it's disabled and inactive). Reboot does not help. Seems like either presets for memkind would need to be adjusted (I hope you know what this thing is, I have no clue :) ) or memkind service would need to be explicitly enabled during installation, i.e.

%post
/sbin/ldconfig
%systemd_post memkind.service
systemctl enable memkind.service

Comment 5 Rafael Aquini 2016-04-28 17:29:01 UTC
(In reply to lukasz.anaczkowski from comment #4)
> Hi Rafael,
> 
> Here's the update:
> 
> 1) 1.0.0 package (both 1 & 2 release) does not have required libmemkind.so.
> It's a fixed bug in memkind src:
> commit fe61f4638cd9ca41fff13aee920084470e451071
> Author: akoziej <artur.koziej>
> Date:   Fri Feb 19 17:39:31 2016 +0100
> 
>     Fix missing libmemkind.so file in memkind RPM.
>     Remove libmemkind.so from memkind-devel.
> 
> Could you pull this in?
> 

May I ask why do you need such change? It doesn't make much sense to me unless you're planning to stop doing soname version --- which is sth not advisable and will hurt Fedora packaging policies.

Shipping the non-versioned soname (even when it's just a symlink to the proper versioned object file) in a -devel subpackage, though it's not a strict rule, is a good practice among packagers in Fedora specially because it's an object that mostly concerns to folks doing devel work on top of a given package. (i.e.: glibc-devel; elfutils-devel)

In the end that ordinary users of a package need is the versioned soname object file so the loader can look up for it and use it.




> 2) after RPM installation, memkind service does not start, nor is enabled
> (i.e. it's disabled and inactive). Reboot does not help. Seems like either
> presets for memkind would need to be adjusted (I hope you know what this
> thing is, I have no clue :) ) or memkind service would need to be explicitly
> enabled during installation, i.e.
> 
> %post
> /sbin/ldconfig
> %systemd_post memkind.service
> systemctl enable memkind.service


Preset files can be overridden by a local administrator, but a set of defaults are provided by Fedora. However, changing a (default) preset for memkind might not be feasible as they're owned by a distro RPM and the decision on them would have to go through distro board. Since this is a quite particular package, it doesn't make much sense to me taking that path.


Explicitly enabling it will not help on your quest of having it automatically started (or activated, in systemd's actual jargon) as that will have to be done manually by the person installing the package anyways, but I don't see any strong argument against adding 'systemctl enable memkind.service' to %post section on the spec. As a matter of fact I believed that %systemd_post macro would expand and do it by itself. I'll adjust memkind.spec to reflect that.


Cheers!
-- Rafael

Comment 6 lukasz.anaczkowski 2016-04-29 12:39:45 UTC
Hi Rafael,

Let us work this through. I'll get back to you next week.

Cheers!
Lukasz

Comment 7 Rafael Aquini 2016-05-13 15:28:10 UTC
(In reply to lukasz.anaczkowski from comment #6)
> Hi Rafael,
> 
> Let us work this through. I'll get back to you next week.
> 

Lukasz, just a reminder this bug is blocking the rhel-7 one.

Regargs,
-- Rafael

Comment 8 lukasz.anaczkowski 2016-05-16 07:43:47 UTC
Hi Rafael,

Sorry for the slip. We are working on memkind service removal and plan to publish this on github next week. Is it ok or should it be done earlier?

Comment 9 Rafael Aquini 2016-05-17 01:02:51 UTC
(In reply to lukasz.anaczkowski from comment #8)
> Hi Rafael,
> 
> Sorry for the slip. We are working on memkind service removal and plan to
> publish this on github next week. Is it ok or should it be done earlier?

Sounds like a plan to me!
Thanks for the feedback.
-- Rafael

Comment 10 Krzysztof Kulakowski 2016-05-23 13:10:49 UTC
(In reply to Rafael Aquini from comment #9)
> (In reply to lukasz.anaczkowski from comment #8)
> > Hi Rafael,
> > 
> > Sorry for the slip. We are working on memkind service removal and plan to
> > publish this on github next week. Is it ok or should it be done earlier?
> 
> Sounds like a plan to me!
> Thanks for the feedback.
> -- Rafael

Hi Rafael,

I would like to notify that we just published memkind 1.1.0. This version is no longer using PMTT service, so this bugzilla is probably no longer needed.

For more details please visit:
   https://github.com/memkind/memkind/releases/tag/v1.1.0 

Best Regards,
Krzysztof.

Comment 11 lukasz.anaczkowski 2016-05-24 07:43:09 UTC
Rafael, please consider pulling src to 1.1.0 as it contains some significant performance improvements. Let me know if separate BZ is needed.

Comment 12 Rafael Aquini 2016-06-09 17:06:09 UTC
Lukasz,

would you mind double-checking this build before we go ahead and start the process for getting this RPM included into RHEL package collections?

http://koji.fedoraproject.org/koji/buildinfo?buildID=771451

Thanks in advance.
-- Rafael

Comment 13 Krzysztof Kulakowski 2016-06-14 11:45:55 UTC
Hi Rafael,

I checked build you provided and everything looks fine to me.

Regards,
Krzysztof.

Comment 14 Fedora Update System 2016-07-05 06:19:11 UTC
memkind-1.1.0-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.