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. :)

from nvme-cli.

Agreed. Thanks for the package. Working on making nvme-cli part of one or more distros...

from nvme-cli.

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.

from nvme-cli.

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.

from nvme-cli.

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?

from nvme-cli.

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?

from nvme-cli.

Great, makes sense. I copied versioning similar to other projects I like using, like git and fio. The release is tagged as v0.1:

https://github.com/linux-nvme/nvme-cli/releases

from nvme-cli.

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.

from nvme-cli.

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

from nvme-cli.

Will try to do a alpinelinux port.

from nvme-cli.

I made an AUR-packet for Arch Linux: https://aur.archlinux.org/packages/nvme-cli-git

If you wanna mention it :)

from nvme-cli.

Submitted for Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1298019

from nvme-cli.

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.

from nvme-cli.

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

from nvme-cli.

It's an official Fedora package. As of around now, you can install it with:

$ dnf --enablerepo=updates-testing install nvme-cli

If you want to help it along into the default updates repo, test it, go to
the update link I posted, open an account, and give it positive feedback.
(That's how all mid-release Fedora changes work.)

from nvme-cli.

The alpine package is on the way, the APKBUILD can be fetched already @ this url
http://tpaste.us/2Koo

from nvme-cli.

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:

sudo dnf install nvme-cli

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.

from nvme-cli.

This is awesome news. Feel free to add to the README and submit a PR.

from nvme-cli.

Commited, http://git.alpinelinux.org/cgit/aports/tree/testing/nvme-cli &
Built https://pkgs.alpinelinux.org/packages?name=nvme%25&repo=all&arch=x86_64&maintainer=all

from nvme-cli.

As of March 1 nvme-cli is now included in the Universe packages for Ubuntu.

batesste@ubuntu-vm:~$ rmadison nvme-cli
nvme-cli | 0.3-1 | xenial/universe | source, amd64, arm64, armhf, i386, powerpc, ppc64el, s390x

from nvme-cli.

Great progress on the packaging front, maybe time to close this issue and open more specific ones as they are needed?

from nvme-cli.

Maybe one last one before the issue is closed. Would it be possible to create a package for EPEL?

from nvme-cli.

Just for the record, an official openSUSE package is available for Tumbleweed and SLES 12 SP2 will contain an official package as well.

from nvme-cli.

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 ;-)!

from nvme-cli.

@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.

from nvme-cli.

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:

1. It's still installs to /opt/nvme-cli/ because I'm lazy and just issued a pull and rebuild.
2. The post.sh install script is pretty gross as it requires make on the machine, however it does mean it's compiled for your system.

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

from nvme-cli.

Could you perhaps give karma to the EL7 package?

--Andy

On Tue, May 10, 2016 at 6:36 PM, Sam [email protected] wrote:

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:

1. It's still installs to /opt/nvme-cli/ because I'm lazy and just
   issued a pull and rebuild.
2. The post.sh install script is pretty gross as it requires make on
   the machine, however it does mean it's compiled for your system.

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/bashcd /opt/nvme-cli
make install

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#14 (comment)

from nvme-cli.

@amluto karma?

from nvme-cli.

from nvme-cli.

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.

from nvme-cli.

from nvme-cli.

Also, to clarify: the correct command to test it appears to be:

yum install nvme-cli --enablerepo=epel-testing

You can also download the RPMs manually from here:

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

from nvme-cli.

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.

from nvme-cli.

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.

from nvme-cli.

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
sudo apt-get update
sudo apt_get install nvme-cli

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:
nvme-list: libudev not detected, install and rebuild.

Does anybody have any suggestions? I apologize as I am not very familiar with Ubuntu and new to the NVME protocol. Thanks

from nvme-cli.

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.

from nvme-cli.

On Jun 14, 2016 2:57 PM, "brentoneal" [email protected] wrote:

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
sudo apt-get update
sudo apt_get install nvme-cli

How about asking sbates to fix it? The Fedora packages get this right, and
presumably Ubuntu should, too.

P.S. nvme-cli should land in EPEL7 very soon, and apparently work is afoot
to get it into RHEL directly.

from nvme-cli.

Not trying to "prescribe" how to do things. But if I may suggest:
The less udev, the better, operationally. As long as there isn't an actual functionality (see around hot-plugging or error management or something) you should check what you gain by relying on libudev itself. Is it more than what ls /dev/nvme* does? more than looking at the holders of the nvme driver, either?

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.
I think that would solve the problem good enough.

from nvme-cli.

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.

from nvme-cli.

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.

from nvme-cli.

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.

from nvme-cli.

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.

from nvme-cli.

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.

from nvme-cli.

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.

from nvme-cli.

@pmmccorm
sorry, but two things with this:
first, the straightforward one:
From the issue tracker I can see so far 3 people had the udev/list issue. I would suggest showing the requirement in the man page. Would it hurt?

second, the other one.
I don't want to drag this into a long discussion.

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.
the logic being that users who install from package are installing on distros with libudev already installed.

Just to raise a finger here:
Most Alpine users don't - there will be mdev and of course no systemd.
I suppose this falls in the unsupported category.
As long as it generally will still work, I'll keep maintaining the package.

But I'd appreciate if you don't make things super-hard just to be more udev dependant.
Others will also be happy: Alpine is like the "fat" end of embedded systems, and I think those will look very similar in some aspects, mainly no dynamic stuff as udev allowed; otherwise it'll end up like a F-35. :-)
They ofc don't need nvme-cli list since they defined their hardware stack.
But they would need the rest nvme-cli for monitoring/maintenance.

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.

from nvme-cli.

I pushed a note to the man page that "list" requires udev:

35450c1

I'll yank it out if we create an alternative for when udev is not available.

from nvme-cli.

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.
0001-print-lbads-out-per-spec.patch.zip

from nvme-cli.

@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.
apk add nvme-cli --update-cache --repository http://dl-3.alpinelinux.org/alpine/edge/testing/ --allow-untrusted

If I install x86-64 apk directly, here is error:
bash-4.3# apk add --allow-untrusted nvme-cli-0.3-r1.apk
ERROR: unsatisfiable constraints:
nvme-cli-0.3-r1:
masked in: cache
satisfies: world[nvme-cli><Q1m6ieZFPpsCCK6IWp7c0zr3MjNuE=]

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,
Roy

from nvme-cli.

Package repos for major distros exist for this tool for a while, so closing

from nvme-cli.