-
Notifications
You must be signed in to change notification settings - Fork 636
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Packages #14
Comments
Thanks for debian package! I'd be very happy to see this provided as an official package in various distributions. Working with some colleagues on that right now, though I can't say I personally know the process to make this so. :) |
Agreed. Thanks for the package. Working on making nvme-cli part of one or more distros... |
One of the things packagers like to see is official releases of some kind, with version numbers. This can come in the form of a github tag or as an official tarball. I couldn't find any indication of version, so I'd have to use 0.DATE.gitHASH or similar as the version number for now. Sam's package is versioned 14.5.2015. I suspect that's May 14th, 2015. |
Having signed tarballs would be even better. Also having some unit tests that can be performed without needing to have a real device installed would be useful. |
This is unfamiliar territory for me ... for versioning, would it be sufficient if we lay a tag down on the repository, call it "v1.0" and have "--version" report the same thing? |
That is sufficient for my purposes. A version number is a signal to your consumers, and that should be taken into account when choosing how and when to do it. A 1.0 version implies some level of interface stability and confidence. You might choose to use 0.1 or similar instead, if you aren't ready for a consumer to stay on the 1.0 version for a while. You might end up making a branch for some consumer who needs a fix cherry-picked because their package guidelines encourage them to not change versions. This can, of course, be done after the fact if it ever comes up. Does that all make sense? |
Great, makes sense. I copied versioning similar to other projects I like using, like git and fio. The release is tagged as v0.1: |
I pushed some package building targets over the last few days and a new tag for version 0.2 that should automatically be incorporated into packages and executable binaries. I think it works (on my machines at least). I hope this is all the right way to put this together. |
Guys FYI we are working on packaging name-cli and posting it into an Ubuntu PPA. I will probably send an email to linux-nvme mailing list when that is done. We will try and use standard packing versioning and I assume/hope launchpad assists in that ;-). Then you can sudo apt-get install nvme-cli if that PPA is in your repo list. Stephen |
Will try to do a alpinelinux port. |
I made an AUR-packet for Arch Linux: https://aur.archlinux.org/packages/nvme-cli-git If you wanna mention it :) |
Submitted for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1298019 |
The Fedora package is approved and is now working its way through the system. You can watch it here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-d174565d42 Hint: it's not very exciting to watch. |
Thanks amluto, this is very cool. Is this then an "official" Fedora package or it is more like an Ubuntu PPA. Great to see distro support for the tool continue to grow. Stephen |
It's an official Fedora package. As of around now, you can install it with:
If you want to help it along into the default updates repo, test it, go to |
The alpine package is on the way, the APKBUILD can be fetched already @ this url |
nvme-clie is now available for real on Fedora. Anyone on Fedora 23 and higher can install it with their favorite package installation tool. For example:
This is the main repository. No special configuration is needed at all. Feel free to mention it in README.md. I'm not planning a Fedora 22 backport unless someone specifically asks for one. If there's demand for an EPEL 7 package, I can probably make that happen, too. |
This is awesome news. Feel free to add to the README and submit a PR. |
As of March 1 nvme-cli is now included in the Universe packages for Ubuntu. batesste@ubuntu-vm:~$ rmadison nvme-cli |
Great progress on the packaging front, maybe time to close this issue and open more specific ones as they are needed? |
Maybe one last one before the issue is closed. Would it be possible to create a package for EPEL? |
Just for the record, an official openSUSE package is available for Tumbleweed and SLES 12 SP2 will contain an official package as well. |
Great news @morbidrsa. The distro support for nvme-cli continues to grow. @nycoe, if you want package support for a given distro I recommend you take on the task and if needed submit a PR for any necessary changes needed to support that package ;-)! |
@nycoe, could you or anyone who has an EL7 (RHEL, CentOS, or otherwise) machine with an nvme device test https://bodhi.fedoraproject.org/updates/nvme-cli-0.5-1.el7 and, if it works, give it positive karma? I don't want to push an update to an enterprise distro if I can't test it. |
FYI - I've updated my nvme-cli.rpm package to the latest code as of today and aligned the versioning to the same as this repo. The package is available from https://packagecloud.io/mrmondo/centos7 Outstanding issues:
built as such: root@dev-samm:/opt/nvme-cli # fpm -s dir -t rpm -n nvme-cli -v 0.6.6.g9539 -p nvme-cli.rpm --after-install=post.sh -d make /opt/nvme-cli
Created package {:path=>"nvme-cli.rpm"}
package_cloud push mrmondo/centos7 nvme-cli.rpm where post.sh is: #/bin/bash
cd /opt/nvme-cli
make install |
Could you perhaps give karma to the EL7 package? --Andy On Tue, May 10, 2016 at 6:36 PM, Sam notifications@github.com wrote:
|
@amluto karma? |
@sammcj: Fedora and EPEL collect user testing on packages to decide whether
they're okay. The feedback is called "karma". Take a look here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-298bf6f19a
If you use CentOS 7 or RHEL 7, and you can test that package (dnf
--enablerepo=epel-testing install nvme-cli [the 'epel-testing' part might
be wrong, but plain rpm can do it too) and it works, if you leave feedback
on that page, it would be great. It's even better if you log in first.
|
Ah, nvme-cli is already available in Fedora, but not in CentOS / RHEL 7 in any form as far as I can tell? Call me stupid (or short of time perhaps), but where is the git repo in which that nvme-cli is coming from? It'd probably make more sense if I just submit a PR to that repo then I'm assuming a CI build would be triggered properly. *Edit - thanks @amluto I've registered an account, agreed to the T&C which are waiting to be approved, and added a comment on the package build which is just a link to this conversation. |
What is the PR and CI you speak of? :) Fedora and EPEL use the Fedora
infrastructure, which generally uses bugzilla instead of PRs.
I made an EL7 package and it's in EPEL 7 testing, but it's not stable
because no one has tested it (except possibly you). Just to clarify, did
you actually test my EPEL 7 rpm?
|
Also, to clarify: the correct command to test it appears to be: yum install nvme-cli --enablerepo=epel-testingYou can also download the RPMs manually from here: |
No CI? ... ouch! I haven't tested your packages, I use my builds of nvme-cli every week against Intel DC3600P 2.5" 1.2TB and Intel 750 PCIe 1.2TB units. I'm currently totally overcommitted with work at present, but hopefully I'll get round to looking at this for Fedora at some point. |
We would love to see this in EPEL Stable. One of my team-members tested it in EL7 and tells me "it looks good". Please let me know if we can help move this forward in any way. |
I'm hoping somebody here can help me with this. I am running Ubuntu and had the nvme-cli installed and working after using the following commands: sudo add-apt-repository ppa:sbates I noticed that the version that installed was not up to date with what is on this github page so I started looking and found the nvme-cli-06.6.g9539-1.x86_64.rpm package above. I downloaded that package, used rpm -i to install. I then went to the /opt/nvme-cli directory that was created and ran the post.sh script to build the package and now runs from /usr/local/sbin/nvme. When I try running nvme-list I get the following: Does anybody have any suggestions? I apologize as I am not very familiar with Ubuntu and new to the NVME protocol. Thanks |
The "list" command is the only one that has a dependency on libudev. Everything else should work. It sounds like the package was compiled on a machine without that library, so we can't fix that. I'd either just not use the "list" sub-command (I don't find it useful anyway until I have more than a handful of NVMe drives in the system), or you could compile this program from source with libudev installed. |
On Jun 14, 2016 2:57 PM, "brentoneal" notifications@github.com wrote:
How about asking sbates to fix it? The Fedora packages get this right, and P.S. nvme-cli should land in EPEL7 very soon, and apparently work is afoot |
Not trying to "prescribe" how to do things. But if I may suggest: Packaging-wise: How about just adding a note to the man page that "list" requires udev. It was easy enough to figure for me but not having to try to debug the util is even easier. |
Yeah, I'm all for having fewer dependencies. It shouldn't be difficult to reimplement 'list' to loop over ls /dev/nvme* instead of using libudev. Until then, I pushed an update to the man page with the suggested note. |
For what it is worth. I'll like libudev to be available to iterate the LightNVM parts. For example is the media manager, targets registered and similar only available through sysfs. |
I have said before: udev listing of nvme devices and related properties should be done by a separate dedicated utility (like lsnvme), and nvme-cli should just handle ioctl related activities. As for packaging and regards to libudev: packaging should handle this. In the RPM spec we can require libudev at compile time, and I'm sure there is some way to do the same for debian packages. Is there a strong case for making libudev optional still? libudev is now rolled into systemd, and every distro that we support has adopted it. |
I know of embedded linux users and cloud vendors who don't have systemd, but use nvme. I'm definitely not suggesting we remove udev functionality from this project. It works well when it's available, but it'd be nice to have alternate implementations when it isn't. |
Hi, I don't chime in much on this, but just throwing it out there, why can't the nvme-cli project offer a static compilation exe (that probably could include libudev) for distros who don't have systemd but use nvme? That way the clean separation Patrick is suggesting can exist, but there would still be a solution for embedded Linux users. |
It is probably a non-issue for embedded users: they compile from source (tarball/git checkout) and things work as expected. For the packages the dependency on libudev has to be chosen at package creation time. I think all the packages should choose to depend on libudev or equivalent: the logic being that users who install from package are installing on distros with libudev already installed. Anyways the issue reported by @FlorianHeigl is solved, the discussion should probably be tracked in a fresh issue if users are running into it. |
@pmmccorm second, the other one.
Just to raise a finger here: But I'd appreciate if you don't make things super-hard just to be more udev dependant. Just asking you keep this in mind a little bit. I'm easy, I'll use it as long as it works :-) But let me know if I can send a tiny man page patch. |
I pushed a note to the man page that "list" requires udev: I'll yank it out if we create an alternative for when udev is not available. |
Hey all, I know the nvme driver code tries to define the various nvme fields the same in its variables/printf() as what is spelled out in the nvme spec. I noticed a small inconsistency in the lbaf fields, which minorly threw me off when I went looking for it in the nvme spec, so I thought I'd offer a patch. Not sure if this is the right place to submit the patch or if there is an email list to send the patch off to, so I've attached it here, per github limitations. |
@FlorianHeigl or others worked on alpine linux distro: I spent hours to dig into installation of nvme-cli on alpine linux, but not succeed yet, tried 3.4, 3.3, and even tried download apk and install it manually, still not OK. If I install x86-64 apk directly, here is error: By the way, I am using Docker container for the work. The environment is OK as I have no issues to install other component from testing repository, like logwatch Any help appreciated! Thanks, |
Package repos for major distros exist for this tool for a while, so closing |
Any plans for official packages for nvme-cli?
In the mean time I've built a Debian package which is available here: https://packagecloud.io/mrmondo/storage - feel free to use it if you wish.
The text was updated successfully, but these errors were encountered: