Update libraw1394 to version 2.0

[Andrew Hunter]

New upstream release of libraw1394, provides compatibility with firewire-core modules.

New diff.gz attached.

[Thomas E Jenkins (thomas-jenkins)]

Heres another update to bring it to 2.0.1. I changed the package soname from -8 to -11 to match what is built. However, I did not make it conflict/replace libraw1394-8 which may or may not be the right thing to do.

[Thomas E Jenkins (thomas-jenkins)]

Heres another update to bring it to 2.0.1. I changed the package soname from -8 to -11 to match what is built. However, I did not make it conflict/replace libraw1394-8 which may or may not be the right thing to do.

[Sebastien Bacher (seb128)]

debian experimental has 2.0.2 shouldn't that version be used for the update rather?

[Andrew Hunter (rexbron)]

Checking the changelog, 2.0.2 is a license fix release. If 2.0.2 is in experimental, then a sync would be preferable.

[Martin Pitt (pitti)]

This needs to be a merge: http://patches.ubuntu.com/libr/libraw1394/libraw1394_1.3.0-4ubuntu1.patch

Also, changing the soname would require a lot of package rebuilds, and testing them. (apt-cache rdepends libraw1394-8). Are you willing to drive that process and test at least some of the reverse dependencies?

[Artem Popov (artfwo)]

If it is okay to merge/test the 2.0 package and it's reverse dependencides after the feature freeze, I'd be happy to do this.

[Steve Langasek (vorlon)]

Karmic is now open; Артём, are you still interested in handling this merge?

Unsubscribing ubuntu-main-sponsors for now since there's no sponsorable merge here at present; please re-subscribe u-m-s again when this is ready for sponsorship.

[Artem Popov (artfwo)]

Yes, I have already tested building several major apps (like VLC, ffado...) against libraw1394-2 and libiec61883-1.2 (copied from Debian) locally on Jaunty. Everything seems to work without problems.

What has to be done to move them into Karmic? Should I proceed with a merge procedure for libraw1394 and sync request for libiec61883? And then just produce lots of nochange-rebuild debdiffs, is that right?

[Artem Popov (artfwo)]

The merge for libraw/libiec is done. The merges are currently in REVU:
(Both are uploaded twice, because of jaunty->karmic mistake in changelog)

http://revu.ubuntuwire.com/details.py?upid=5639 - libraw1394
http://revu.ubuntuwire.com/details.py?upid=5640 - libiec61883

I'd like request sponsorship for both libiec61883 and libraw1394 here, because libiec61883 in Ubuntu is also stuck at a deprecated version and it is heavily connected to libraw1394 anyway. Thanks!

[Artem Popov (artfwo)]

A debdiff for the libraw1394 merge above.

[Artem Popov (artfwo)]

A debdiff for the libiec61883 merge above.

[Steve Langasek (vorlon)]

Thanks, I'll take care of sponsoring the libraw1394 merge.

libiec61883 happens to have become a sync now, no need to merge that.

There's also no need to generate debdiffs for reverse-dependencies - since those changes will be trivial, Ubuntu developers will handle those directly. If there are any reverse-deps that are known to fail to build with the new libraw1394, help with fixing those would be appreciated.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libraw1394 - 2.0.2-2ubuntu1

---------------
libraw1394 (2.0.2-2ubuntu1) karmic; urgency=low

  * Merge from Debian unstable (LP: #311804), remaining changes:
    - debian/README.Debian: Corrected file to use sudo instead of running
      as root

libraw1394 (2.0.2-2) unstable; urgency=low

  * Upload to unstable.

libraw1394 (2.0.2-1) experimental; urgency=low

  * New upstream release. Closes: #499775
    - Supports the juju stack. Closes: #434551, #453358

 -- Aerteieem PEopeove <email address hidden> Mon, 04 May 2009 10:12:18 +0700