Description of problem: The latest kernel from Fedora 21 is compiled with the newly introduced support for USB-over-IP (CONFIG_USBIP_CORE) and correspondiing tools disabled. It would be nice if they were available. Version-Release number of selected component (if applicable): 3.17.4 from Fedora 21
Created attachment 965996 [details] Enable USBIP kernel modules
Created attachment 965997 [details] Add USBIP userspace tools
Just to add some context, USBIP was enabled in the RPM Fusion staging kmod for the last few releases. I've ported this from my original work with the RPM Fusion spec to the kernel spec. rpmlint is complaining about running ldconfig after install usbip and the fact that the binaries in usbip aren't stripped. The first is easily fixed, and I'm not sure if the second is related to building the kernel using "rpmbuild -bb --with baseonly --without debuginfo --target=`uname -m` kernel.spec"
I was wondering what happened to the RPMFusion packages. Thank you very much for the patches, I'll try them out ASAP.
(In reply to Jonathan Dieter from comment #1) > Created attachment 965996 [details] > Enable USBIP kernel modules This one looks good. I think I can apply it as-is. (In reply to Jonathan Dieter from comment #2) > Created attachment 965997 [details] > Add USBIP userspace tools This one is fine if we want to add yet another subpackage. I'm not sure we do though. Is there any reason we couldn't ship these in the existing kernel-tools subpackage? Also, unless I'm missing something, the .service and .configuration files are missing.
(In reply to Josh Boyer from comment #5) > (In reply to Jonathan Dieter from comment #1) > > Created attachment 965996 [details] > > Enable USBIP kernel modules > > This one looks good. I think I can apply it as-is. > > (In reply to Jonathan Dieter from comment #2) > > Created attachment 965997 [details] > > Add USBIP userspace tools > > This one is fine if we want to add yet another subpackage. I'm not sure we > do though. Is there any reason we couldn't ship these in the existing > kernel-tools subpackage? > > Also, unless I'm missing something, the .service and .configuration files > are missing. Actually, looking at it more, there are a couple other questions/comments. 1) We dont' want to explicity require kernel-modules-extra anymore. If we move the module later then we have to adjust the Requires manually. Just require the actual module since the kernel auto-generates provides for all .ko files. 2) Why does this BuildRequire: systemd? 3) Why doesn't it BuildRequire:automake (or whatever is used to generate configure) and libtool? The more I look at this, the more I think it would be better to just split out the sources into their own SRPM and build the package entirely separate. There's a lot of stuff here that is very userspace-ish. The kernel maintainers aren't going to build this and ship it with the expectation that we'll actually be in a position to support it. It would be better for it to have a proper maintainer on the userspace side.
(In reply to Josh Boyer from comment #6) > (In reply to Josh Boyer from comment #5) > > (In reply to Jonathan Dieter from comment #1) > > > Created attachment 965996 [details] > > > Enable USBIP kernel modules > > > > This one looks good. I think I can apply it as-is. > > > > (In reply to Jonathan Dieter from comment #2) > > > Created attachment 965997 [details] > > > Add USBIP userspace tools > > > > This one is fine if we want to add yet another subpackage. I'm not sure we > > do though. Is there any reason we couldn't ship these in the existing > > kernel-tools subpackage? Because it's so specific to a certain use-case, I thought it made more sense to split off. I'm not averse to merging it into the kernel-tools subpackage if you feel strongly about it. > > > > Also, unless I'm missing something, the .service and .configuration files > > are missing. My fault. Let me attach them. > Actually, looking at it more, there are a couple other questions/comments. > > 1) We dont' want to explicity require kernel-modules-extra anymore. If we > move the module later then we have to adjust the Requires manually. Just > require the actual module since the kernel auto-generates provides for all > .ko files. Ok, will do. > 2) Why does this BuildRequire: systemd? http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptlets_.28Fedora_18.2B.29 This says we're supposed to BR systemd, not sure why. > 3) Why doesn't it BuildRequire:automake (or whatever is used to generate > configure) and libtool? This is my bad. I didn't build it through mock, just a local rpmbuild, so I missed that one. I'll fix that. > The more I look at this, the more I think it would be better to just split > out the sources into their own SRPM and build the package entirely separate. > There's a lot of stuff here that is very userspace-ish. The kernel > maintainers aren't going to build this and ship it with the expectation that > we'll actually be in a position to support it. It would be better for it to > have a proper maintainer on the userspace side. I understand your position, but the problem is that the userspace seems to be pretty tightly bound with the kernel, which means we'll have to be rebuilding it at least for every major version upgrade. If it helps at all, I don't mind being the go-to person here and having all USBIP bugs assigned to me. If you still feel strongly that you don't want it built by the kernel SRPM, then I'll happily split it into a separate SRPM. I'll go ahead and update the second patch to fix the mistakes listed above.
Created attachment 969645 [details] Add USBIP userspace tools
Created attachment 969646 [details] Add USBIP userspace tools Just realized I was depending on the wrong kmod. Fixed.
Created attachment 969660 [details] Add USBIP userspace tools While I'm at it, run ldconfig in %post and %postun
(In reply to Jonathan Dieter from comment #7) > > The more I look at this, the more I think it would be better to just split > > out the sources into their own SRPM and build the package entirely separate. > > There's a lot of stuff here that is very userspace-ish. The kernel > > maintainers aren't going to build this and ship it with the expectation that > > we'll actually be in a position to support it. It would be better for it to > > have a proper maintainer on the userspace side. > > I understand your position, but the problem is that the userspace seems to > be pretty tightly bound with the kernel, which means we'll have to be > rebuilding it at least for every major version upgrade. That's a reasonable assumption to make, but it hasn't actually proven to be true. The usbip tools were merged into mainline out of staging in the 3.17 kernel, as you mentioned. Since 3.17 was released, there has been a grand total of 2 commits to that entire directory. Neither one of those looks like it would actually impact anything other than the internal code organization. It isn't what I'd call a high churn source base. By having it in the kernel-tools package (or any other subpackage via the kernel SRPM) we wind up building the same package over and over again for no benefit.
(In reply to Josh Boyer from comment #11) > (In reply to Jonathan Dieter from comment #7) > > I understand your position, but the problem is that the userspace seems to > > be pretty tightly bound with the kernel, which means we'll have to be > > rebuilding it at least for every major version upgrade. > > That's a reasonable assumption to make, but it hasn't actually proven to be > true. The usbip tools were merged into mainline out of staging in the 3.17 > kernel, as you mentioned. Since 3.17 was released, there has been a grand > total of 2 commits to that entire directory. Neither one of those looks > like it would actually impact anything other than the internal code > organization. It isn't what I'd call a high churn source base. By having > it in the kernel-tools package (or any other subpackage via the kernel SRPM) > we wind up building the same package over and over again for no benefit. Ok, good point. On a related note, if I split userspace off into a separate SRPM, should I work from the full kernel source or should I pull the userspace out and tar it up (with full comments in the spec)? I'm just not sure how reasonable it is to have a 77MB source for a <100KB package.
I would go with pulling out the userspace part and tarring it up. I agree it doesn't make much sense to carry the full kernel tarball.
Ok, I've gone ahead and put together a quick package that passes rpmlint, but it's late here so I'll put it up for review tomorrow. If you didn't mind applying the first patch enabling the kernel modules to all releases that have the 3.17 kernel, I'd greatly appreciate it. Since we've had these modules in RPM Fusion for a while, it will provide a nice upgrade path.
Ok, I've created a review request at #1175270. If any packager reading this is interested in getting the USB/IP userspace into Fedora, please review it.
OK, I've applied the first patch to the kernel for f21 and rawhide today. Thanks Johnathan.
Thanks so much. If I also wanted the first patch applied for f19 and f20, should I post separate patches against those branches? The only reason I care about f19 and f20 is that they had USB/IP supported in RPM Fusion's kmod-staging up until the 3.17 kernel came out, but it's been removed in the 3.17 kmod-staging. (Full disclosure, it's completely my fault that this didn't get dealt with sooner. Thorsten gave me a heads up back in the middle of September, but I dropped the ball.)
Fedora 19 is getting only critical security fixes until it goes EOL, and it isn't going to be rebased to 3.17 anyway. I don't see a need for change there. F20 we can look at tomorrow. I'm out of time today.
(In reply to Josh Boyer from comment #18) > Fedora 19 is getting only critical security fixes until it goes EOL, and it > isn't going to be rebased to 3.17 anyway. I don't see a need for change > there. Sorry, for some reason I thought it had been rebased to 3.17. You're completely right. > F20 we can look at tomorrow. I'm out of time today. That's fine. Thanks so much.
OK, F20 is now updated as well.
Thanks so much.
kernel-3.17.8-300.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/kernel-3.17.8-300.fc21
kernel-3.17.8-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.17.8-200.fc20
Package kernel-3.17.8-200.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.17.8-200.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-0515/kernel-3.17.8-200.fc20 then log in and leave karma (feedback).
kernel-3.17.8-300.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
kernel-3.17.8-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
For those not watching https://bugzilla.redhat.com/show_bug.cgi?id=1175270, the USB/IP userspace has been built and should be in -testing for F21 and F20 in the next compose (and should already be in Rawhide).
I just realized that the F20 kernel still doesn't have the kernel modules. Can you please add them in to the next F20 kernel?
Josh, sorry for the noise in the previous comment. I don't know which kernel version I was looking at, but the kernel modules were indeed built for 3.17.8-200.fc20.