Ubuntu

usbip source is maintained in kernel tree now

Reported by Rockwalrus on 2011-11-30
88
This bug affects 19 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Low
Unassigned
usbip (Ubuntu)
Undecided
Unassigned

Bug Description

Both the userspace and kernel module parts of usbip are in the linux kernel tree now. The source used in this package is quite old.

I'm not sure how to best handle the packaging aspects here -- I imagine that it would be undesirable for usbip to be built as a side effect of the main kernel package build, because then the kernel package build would be even slower and usbip is probably not updated enough to justify that.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 898003

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Rockwalrus (rockwalrus) wrote :

Log files are irrelevant to a change in SCM location. :)

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
tags: added: bot-stop-nagging
Changed in linux (Ubuntu):
importance: Undecided → Low
Rockwalrus (rockwalrus) wrote :
Rockwalrus (rockwalrus) wrote :
Rockwalrus (rockwalrus) wrote :
Rockwalrus (rockwalrus) wrote :
Rockwalrus (rockwalrus) wrote :
Rockwalrus (rockwalrus) wrote :
Rockwalrus (rockwalrus) wrote :
Rockwalrus (rockwalrus) on 2011-11-30
Changed in usbip (Ubuntu):
status: New → Confirmed
Evan Broder (broder) wrote :

Thanks for your work on getting these packages updated, and I'm sorry that it's taken so long to get this looked at.

I asked the kernel team about building the usbip packages as part of the kernel build process:

1:18 PM <broder> i'm wondering whether or not it would be plausible to incorporate the usbip userspace pieces into the kernel package build (there's a client, a server, and a library), or whether we should keep snapshotting the source from the kernel into a separate source package
1:19 PM <tgardner> broder, looking
1:23 PM <tgardner> broder, this is still a staging driver. while we have a mechanism for building and distributing applications from the kernel source tree, I'm not sure I wanna bother with a staging driver.
1:25 PM <broder> tgardner: ok. that's reasonable. it doesn't seem like it's going through a whole lot of churn anyway
1:26 PM <broder> i'll work on updating the separate package
1:26 PM <tgardner> broder, maybe we can pick it up when it gets promoted to mainline

For now, I'm going to mark the bug task on Linux as invalid.

I'm also happy to try and review your packing updates. I have a few questions/concerns so far:

 - Where did the -2.5- in the version number come from? Was that the kernel version number when you snapshotted it? I'm assuming at this point that the package is out of date from the current kernel

 - Since the 3.0.0 version of the packaging was never uploaded to Ubuntu, there should only be a single changelog entry for 3.2.0 (similarly, the debian/NEWS file should be updated)

 - The changelog should be more explicit about changes to the packaging. In particular, it would be good to see some discussion about the debian/header/* files

 - Please use XS-Debian-Vcs-Browser and -Vcs-Git instead of -Original- (see https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023332.html)

 - As more of a wishlist thing, we generally prefer dkms-based kernel module packages over module-assistant based ones these days. It would be excellent to have a usbip-dkms in addition to (or instead of) usbip-source

If you'd like to update the packaging to address all of these, that's fine. If not, I'm happy to do the cleanup, but I need a hint on the version number to move forward.

(I'm unsubscribing ubuntu-sponsors for the time being, but feel free to resubscribe them when you feel you've addressed my concerns)

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix
Whoopie (whoopie79) wrote :

I packaged the usbip-utils slightly different. I copied the userspace directory from the kernel and tar'ed it. Then, I removed all unimportant stuff from the debian folder (including the usbip-source package).

The result can be found in my testing PPA. Could some of the ubuntu devs please have a look?

Whoopie (whoopie79) wrote :

I did another cleanup round and simplified the debian/rules a lot. The updated package can be found in my testing PPA (https://launchpad.net/~whoopie79/+archive/testing/+packages).

Whoopie (whoopie79) wrote :

I just saw that the usbip-utils package has a version numer of 1.1.1 (see https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=0aee58894551d7a9992f79d77d89f5846eb5e938).

I uploaded a new package in my PPA (https://launchpad.net/~whoopie79/+archive/ppa/+packages) with the correct version number.

James Page (james-page) wrote :

Hi Whoopie

As discussed in #ubuntu-devel:

1) You should make contact with the Debian Maintainer - at some point in time they are going to hit the same problem and you have made alot of packaging changes with this update - we need to ensure that this is a delta and not a permanent fork because he disagrees with the way we have done things re packaging and approach.

2) Documentation; as you have done quite a bit of packaging change and altered the way the orig.tar.gz is created this really needs documenting both in the changelog and in debian/README.source,watch so that if some else touches this in the future they can follow the same processes. Also worth noting why the -source package is being dropped -most people won't look in the bug report.

I think that trying to keep and approach+packaging inline with Debian but using a different upstream version/source is the best way forwards in this case.

Michael Markstaller (makki) wrote :

It would be good to get this resolved, it worked basically some months back but now with the change from SF to kernel-tree things are fully messed up somehow (12.04), the modules on the client cannot be loaded at all and cannot connect to a recent server (on OpenWRT, kernel 3.3.5) due to "version mismatch: 262 273"

Michael

P.S.: bug/994934 looks related/same issue

Chris Halse Rogers (raof) wrote :

Hi Whoopie:

I've unsubscribed sponsors; James' comments should be addressed before we upload anything. Are you planning to address these issues?

Whoopie (whoopie79) wrote :

The usbip package is now built inside of linux-tools in Debian. Would it be possible to do the same?

See http://packages.debian.org/changelogs/pool/main/l/linux-tools/linux-tools_3.2.17-1/changelog

Nicolas Delvaux (malizor) wrote :

As Whoopie said, this bug is now fixed in Debian, so there is just Ubuntu now.
AFAIK it is still not fixed in Raring...

@Whoopie: I don't see the usbip package in your PPA, could you re-upload it (at least for Precise)? It would be appreciated :-)

Whats the progress on this?
On my Raspberry Pi (wheezy) I have version 1.1.1:

usbip version
usbip (usbip-utils 1.1.1)

On Ubuntu Raring I have version 0.1.7 which seems to be hopelessly outdated:
usbip -v

** (process:19658): WARNING **: running non-root?
usbip 0.1.7 ($Id: vhci_attach.c 42 2007-09-07 12:07:51Z hirofuchi $)

These two different versions don't seem to work with each other:

Command (Client / Raring)
sudo usbip -D --list 192.168.178.35
usbip dbg: usbip_network.c: 221 (tcp_connect ) trying 192.168.178.35 port 3240

usbip dbg: usbip_network.c: 241 (tcp_connect ) connected to 192.168.178.35:3240
- 192.168.178.35
usbip err: usbip_network.c: 119 (usbip_recv_op_common) recv op_common, -1
usbip err: vhci_attach.c: 202 (query_exported_devices) recv op_common
usbip err: vhci_attach.c: 417 (show_exported_devices) query

Messages (Server / Wheezy)
sudo usbipd
usbipd: info: starting usbipd (usbip-utils 1.1.1)
usbipd: info: listening on 0.0.0.0:3240
usbipd: info: connection from 192.168.178.32:36593

@Whoopie: Could you make your packages available for Raring?

This seems to be broken for all current kernels paired with package version 0.1.7.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers