lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 6 Mar 2014 08:17:18 -0800
From:	Greg KH <>
To:	Andrew Grover <>,
	Valentina Manea <>
	"Linux Kernel Community @ ROSEdu" <>,,
Subject: Re: [PATCH] staging: usbip: userspace: increase version to 2.0

On Wed, Mar 05, 2014 at 11:30:06PM -0800, Andrew Grover wrote:
> On Wed, Mar 5, 2014 at 10:14 PM, Valentina Manea
> <> wrote:
> > On Tue, Mar 4, 2014 at 9:20 PM, Greg KH <> wrote:
> >> On Tue, Mar 04, 2014 at 09:16:39PM +0200, Valentina Manea wrote:
> >>> -AC_INIT([usbip-utils], [1.1.1], [])
> >>> +AC_INIT([usbip-utils], [2.0], [])
> >>
> >> Why?
> >>
> >> What does this mean?  What warrents the version change?  Why have a
> >> version at all?
> >
> > This was part of an effort to "refresh" USB/IP by moving userspace out
> > of kernel.git.
> > Since some major changes have been made (libudev migration), Andy (cc'ed) and me
> > thought it was worth to be promoted to version 2.0.
> (sorry, resending in plain text mode so vger doesn't bounce (curse you
> gmail :-))
> Valentina did considerable work in moving usbip-utils from using the
> defunct libsysfs to libudev (well, part of systemd now it seems.) so
> some version bump seems appropriate, why not to 2.0? esp. as a
> heads-up to pkg maintainers - btw usbip-utils is already packaged for
> Debian, and I could probably see it in Fedora too, why not.
> As to why have a version at all, this is of course tied to whether
> usbip-utils will ever emerge from the belly of the whale and return to
> its own home. I think it should someday, if the concerns about
> long-term maintenance and interface stability can be addressed to your
> satisfaction. It would be considerable work to integrate it into the
> kernel build, and would need to be undone if it ever left kernel.git.

One big confusion this patch caused, is that it showed up "on its own"
before the "libudev rewrite" in my inbox.  So all I see is this patch
incrementing the version for no real reason.

Valentina, please always order all of your patches so I know which order
in which to apply them in.  I see a bunch of follow-on patches after
your larger series, what order should they be applied in?  Can you just
resend _all_ of these, and number them in the correct order in which
they need to be applied in, so I know exactly what to do here?


greg k-h
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists