Ubuntu
jockey package

Jockey will fail against local disk archive

Bug #913927 reported by James Ferguson
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OEM Priority Project
Fix Released
High
Unassigned
Precise
Fix Released
Undecided
Unassigned
jockey (Ubuntu)
Fix Released
Medium
Martin Pitt

Bug Description

Ubuntu 11.10
Jockey 0.9.4-0ubuntu10

Some logic looks problematic and is causing jockey to fail to find drivers on our on-disk repositories. Local on-disk archives are used a lot in OEM on customer's first boot. We are currently carrying patches to Jockey for a number of OEM projects to get around this.

I have found 3 issues in the code related to this:

1. The code in OSLib::has_repositories assumes URIs - "://" from apt-cache policy. If the archive is file based it will be "file:/foo/bar/..." and so will not satisfy the test.

2. There is also a similar problem in the detection.py code - DriverDB::_cache_id(self), which also assumes a "://". When I altered it to this (along with fixing the above) jockey worked as I would hope:

    m = re.match(".*::/{1,2}(.*)")
    if m:
         u = m.group(1)

But I'm not sure if that's sufficiently tight? Perhaps ".*(file:/|://)(.*)", and then group(2)?

3. The on-disk binary drivers will be unsigned, so will fail. I would think an appropriate solution would be to allow the signature checking to be turned off with a command line option.

See original description
Revision history for this message
James Ferguson (jamesf) wrote :

I initially thought this was a newly introduced issue in the -proposed version, but I was wrong - edited but to reflect this.

summary: - Jockey will fail against local disk archive (regression in -proposed)
+ Jockey will fail against local disk archive
description: updated
James Ferguson (jamesf)
description: updated
James Ferguson (jamesf)
description: updated
James Ferguson (jamesf)
Changed in oem-priority:
importance: Undecided → High
status: New → Confirmed
status: Confirmed → New
Revision history for this message
James M. Leddy (jm-leddy) wrote :

Hello James,

You mentioned that you're carrying patches to address these issues. Would you please attach to the bug report?

Changed in oem-priority:
status: New → Incomplete
Changed in jockey (Ubuntu):
status: New → Incomplete
Kevin Krafthefer (krafthefer)
Changed in oem-priority:
assignee: nobody → Ursula Junque (ursinha)
Kevin Krafthefer (krafthefer)
tags: added: rls-mgr-p-tracking
Revision history for this message
James Ferguson (jamesf) wrote :

Attached is the relevant patch.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "jockey.diff" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
James Ferguson (jamesf)
tags: removed: patch
Revision history for this message
Martin Pitt (pitti) wrote :

+ m = re.match(".*(file:/|://)(.*)", u)

I don't understand why this is necessary. file apt sources should still be complete URLs, i. e. file://relative_path or file:///absolute/path. file:/path/name/ is not a real URL, and I don't want to support this. And of course I don't want to allow unsigned binary archives in the official ubuntu package.

Revision history for this message
James Ferguson (jamesf) wrote :

@Pitti - perhaps a bug in `apt-cache policy`? It reports them as "file:/foo/bar". The archive was created as a directory on the system, with $ARCHIVE as an absolute path (having moved aside the real sources.list temporarily):

    cd "$ARCHIVE"
    apt-ftparchive packages . | gzip -n9 > Packages.gz
    echo "deb file://$ARCHIVE" > /etc/apt/sources.list

As for unsigned binary archives, jockey considers the packages from the above archive unsigned and refuses them. Any way to get around this is fine.

Martin Pitt (pitti)
Changed in jockey (Ubuntu):
status: Incomplete → In Progress
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Medium
Chris Van Hoof (vanhoof)
Changed in oem-priority:
status: Incomplete → In Progress
Ursula Junque (ursinha)
Changed in oem-priority:
assignee: Ursula Junque (ursinha) → nobody
Martin Pitt (pitti)
tags: added: rls-p-tracking
removed: rls-mgr-p-tracking
Martin Pitt (pitti)
Changed in jockey (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package jockey - 0.9.7-0ubuntu1

---------------
jockey (0.9.7-0ubuntu1) precise; urgency=low

  * New upstream bug fix release:
    - jockey/detection.py: Accept repository URLs with "file:/", too
    - jockey/oslib.py: Completely parse PackageKit output. Thanks Hedayat
      Vatankhah! (LP: #900853)
    - gtk/jockey-gtk: Create tray icon when indicator support is not
      available. Thanks Hedayat Vatankhah! (LP: #900824)
    - Launchpad automatic translations update.
  * jockey/oslib.py, has_repositories(): Also accept "file:/path..." URLs from
    apt-cache policy to recongize local repositories. First half of LP #913927.
    Thanks to James Ferguson for the patch.
  * jockey/oslib.py, install_package(): Consider file:// URLs a trusted
    origin even for binary packages. (LP: #913927)
  * tests/oslib.py: Update test_package_install_thirdparty_unsigned_binary()
    test to use a http:// URL, as file:// URLs are now considered trusted.
 -- Martin Pitt <email address hidden> Sat, 03 Mar 2012 22:30:37 +0100

Changed in jockey (Ubuntu):
status: Fix Committed → Fix Released
Kevin Krafthefer (krafthefer)
Changed in oem-priority:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.