Merge version 1.0.11-0+deb10u5+rpi1 and 1.0.11-0+deb10u6 to produce 1.0.11-0+deb10u6+rpi1

Merge libde265 (1.0.11-0+deb10u6) import into refs/heads/workingbranch

CVE-2023-49468

commit 3e822a3ccf88df1380b165d6ce5a00494a27ceeb
Author: Dirk Farin <dirk.farin@gmail.com>
Date:   Thu Nov 23 19:11:34 2023 +0100

    fix #432 (undefined IPM)

Gbp-Pq: Name CVE-2023-49468.patch

CVE-2023-49467

commit 7e4faf254bbd2e52b0f216cb987573a2cce97b54
Author: Dirk Farin <dirk.farin@gmail.com>
Date:   Thu Nov 23 19:38:34 2023 +0100

    prevent endless loop for #434 input

Gbp-Pq: Name CVE-2023-49467.patch

CVE-2023-49465

commit 1475c7d2f0a6dc35c27e18abc4db9679bfd32568
Author: Dirk Farin <dirk.farin@gmail.com>
Date:   Thu Nov 23 19:43:55 2023 +0100

    possible fix for #435

Gbp-Pq: Name CVE-2023-49465.patch

[PATCH] null-pointer check in debug output (fixes #426)

Gbp-Pq: Name CVE-2023-47471.patch

[PATCH] fix #418

Gbp-Pq: Name CVE-2023-43887.patch

[PATCH] check for valid slice header index access (fixes #394)

Gbp-Pq: Name CVE-2023-27103.patch

[PATCH] check whether referenced PPS exists (fixes #393)

Gbp-Pq: Name CVE-2023-27102.patch

[PATCH] Don't update sps if they are only repeated

This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:

> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".

This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.

Gbp-Pq: Name recycle_sps_if_possible.patch

[PATCH] Use the sps from the image

(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  #336 - CVE-2022-43238
 - poc4  #338 - CVE-2022-43241
 - poc6-1, poc6-2 #340 - CVE-2022-43242
 - poc7-1, poc7-2  #341 - CVE-2022-43239
 - poc8-1 #342 - CVE-2022-43244
 - poc9-3 #343 - CVE-2022-43236
 - poc10-2, poc10-3 #344 - CVE-2022-43237
 - poc16 #350
 - poc19 #353

The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)

 - poc1  #335 - CVE-2022-43240
 - poc3  #337 - CVE-2022-43235
 - poc5   #339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  #343 - CVE-2022-43236
 - poc14  #348 - CVE-2022-43253
 - poc15  #349 - CVE-2022-43248
 - poc17-1, poc17-2  #351
 - poc18 #352 - CVE-2022-43245

Gbp-Pq: Name use_sps_from_the_image.patch

[PATCH] Try to mitigate asan failures.

See #345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (#337)
- poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (#345) CVE-2022-43249
- poc12 (#346)
- poc13 (#347) CVE-2022-43252
- poc16 (#350)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.11-0+deb10u6) buster-security; urgency=high

  * Non-maintainer upload by the LTS Team.
  * CVE-2023-49465
    heap-buffer-overflow in derive_spatial_luma_vector_prediction()
  * CVE-2023-49467
    heap-buffer-overflow in derive_combined_bipredictive_merging_candidates()
  * CVE-2023-49468
    global buffer overflow in read_coding_unit()

[dgit import unpatched libde265 1.0.11-0+deb10u6]

Import libde265_1.0.11-0+deb10u6.debian.tar.xz

[dgit import tarball libde265 1.0.11-0+deb10u6 libde265_1.0.11-0+deb10u6.debian.tar.xz]

Merge version 1.0.11-0+deb10u4+rpi1 and 1.0.11-0+deb10u5 to produce 1.0.11-0+deb10u5+rpi1

Merge libde265 (1.0.11-0+deb10u5) import into refs/heads/workingbranch

[PATCH] null-pointer check in debug output (fixes #426)

Gbp-Pq: Name CVE-2023-47471.patch

[PATCH] fix #418

Gbp-Pq: Name CVE-2023-43887.patch

[PATCH] check for valid slice header index access (fixes #394)

Gbp-Pq: Name CVE-2023-27103.patch

[PATCH] check whether referenced PPS exists (fixes #393)

Gbp-Pq: Name CVE-2023-27102.patch

[PATCH] Don't update sps if they are only repeated

This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:

> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".

This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.

Gbp-Pq: Name recycle_sps_if_possible.patch

[PATCH] Use the sps from the image

(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  #336 - CVE-2022-43238
 - poc4  #338 - CVE-2022-43241
 - poc6-1, poc6-2 #340 - CVE-2022-43242
 - poc7-1, poc7-2  #341 - CVE-2022-43239
 - poc8-1 #342 - CVE-2022-43244
 - poc9-3 #343 - CVE-2022-43236
 - poc10-2, poc10-3 #344 - CVE-2022-43237
 - poc16 #350
 - poc19 #353

The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)

 - poc1  #335 - CVE-2022-43240
 - poc3  #337 - CVE-2022-43235
 - poc5   #339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  #343 - CVE-2022-43236
 - poc14  #348 - CVE-2022-43253
 - poc15  #349 - CVE-2022-43248
 - poc17-1, poc17-2  #351
 - poc18 #352 - CVE-2022-43245

Gbp-Pq: Name use_sps_from_the_image.patch

[PATCH] Try to mitigate asan failures.

See #345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (#337)
- poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (#345) CVE-2022-43249
- poc12 (#346)
- poc13 (#347) CVE-2022-43252
- poc16 (#350)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.11-0+deb10u5) buster-security; urgency=medium

  * Non-maintainer upload by the LTS Security Team.
  * Fix: CVE-2023-27102, CVE-2023-27103, CVE-2023-43887 and CVE-2023-47471.

[dgit import unpatched libde265 1.0.11-0+deb10u5]

Import libde265_1.0.11-0+deb10u5.debian.tar.xz

[dgit import tarball libde265 1.0.11-0+deb10u5 libde265_1.0.11-0+deb10u5.debian.tar.xz]

Merge version 1.0.3-1+rpi1+deb10u1 and 1.0.11-0+deb10u4 to produce 1.0.11-0+deb10u4+rpi1

Import libde265_1.0.11.orig.tar.gz

[dgit import orig libde265_1.0.11.orig.tar.gz]

Merge libde265 (1.0.11-0+deb10u4) import into refs/heads/workingbranch

[PATCH] Don't update sps if they are only repeated

This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:

> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".

This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.

Gbp-Pq: Name recycle_sps_if_possible.patch

[PATCH] Use the sps from the image

(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  #336 - CVE-2022-43238
 - poc4  #338 - CVE-2022-43241
 - poc6-1, poc6-2 #340 - CVE-2022-43242
 - poc7-1, poc7-2  #341 - CVE-2022-43239
 - poc8-1 #342 - CVE-2022-43244
 - poc9-3 #343 - CVE-2022-43236
 - poc10-2, poc10-3 #344 - CVE-2022-43237
 - poc16 #350
 - poc19 #353

The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)

 - poc1  #335 - CVE-2022-43240
 - poc3  #337 - CVE-2022-43235
 - poc5   #339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  #343 - CVE-2022-43236
 - poc14  #348 - CVE-2022-43253
 - poc15  #349 - CVE-2022-43248
 - poc17-1, poc17-2  #351
 - poc18 #352 - CVE-2022-43245

Gbp-Pq: Name use_sps_from_the_image.patch

[PATCH] Try to mitigate asan failures.

See #345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (#337)
- poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (#345) CVE-2022-43249
- poc12 (#346)
- poc13 (#347) CVE-2022-43252
- poc16 (#350)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

Disable building of some internal tools that no longer link

because internal symbols are no longer exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.11-0+deb10u4) buster-security; urgency=medium

  * Non-maintainer upload by the LTS Security Team.
  * Import new upstream version, based on the 1.0.11-0+deb11u1 package
    from bullseye.
    - fixing:
      CVE-2023-24751, CVE-2023-24752, CVE-2023-24754, CVE-2023-24755,
      CVE-2023-24756, CVE-2023-24757, CVE-2023-24758 and CVE-2023-25221.
    - dropping no longer needed patches that have been integrated or
      made obsolete by the new upstream version.

[dgit import unpatched libde265 1.0.11-0+deb10u4]

Import libde265_1.0.11.orig.tar.gz

[dgit import orig libde265_1.0.11.orig.tar.gz]

Import libde265_1.0.11-0+deb10u4.debian.tar.xz

[dgit import tarball libde265 1.0.11-0+deb10u4 libde265_1.0.11-0+deb10u4.debian.tar.xz]

Merge libde265 (1.0.3-1+deb10u3) import into refs/heads/workingbranch

[PATCH] reference PPS from slice by shared_ptr to prevent usage after deallocation

Gbp-Pq: Name fix-use-after-free.patch

[PATCH] initialize newly created CABAC model table when (fixes #236)

Gbp-Pq: Name CVE-2020-21596-global-buffer-overflow.patch

[PATCH] SAO: fix illegal table access when input pixel is out of range (fixes #351)

Gbp-Pq: Name CVE-2022-43245-fix-asan-wildpointer-apply_sao_internal.patch

[PATCH] check for negative Q-values in invalid input streams

Gbp-Pq: Name check-4-negative-Q-value.patch

[PATCH] Don't update sps if they are only repeated

This is an attempt to improve the mitigations from #365 and #366 and picks up an idea I described at #345:

> One way would be just to look at the pointers of the SPS (fast and easy, but
> may reject more than required), or investigate if the SPS used for the image
> generations are "compatible".

This changes do exactly this: It (very conservativly) checks if the old and new sps have
identical information -- except the reference picture set, which I believe is supposed
to be updated by new sps'). If they are basically identical, the old sps will be
used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library;
if an ABI bump would be done, of course this should go to the respective classes.

Gbp-Pq: Name recycle_sps_if_possible.patch

[PATCH] Use the sps from the image

(as e.g mc_chroma is using the sps to determine
picture properties, like pic_width_in_luma_samples
and pic_height_in_luma_samples, I *think* this is
more correct.

This PR is for discussion. (See #345.)
It makes the failures go away, but that does not mean it's correct :)

The following poc will be stop failing if (only) this
patch is applied:

 - poc2  #336 - CVE-2022-43238
 - poc4  #338 - CVE-2022-43241
 - poc6-1, poc6-2 #340 - CVE-2022-43242
 - poc7-1, poc7-2  #341 - CVE-2022-43239
 - poc8-1 #342 - CVE-2022-43244
 - poc9-3 #343 - CVE-2022-43236
 - poc10-2, poc10-3 #344 - CVE-2022-43237
 - poc16 #350
 - poc19 #353

The following are still failing if only this patch is
applied, but they stop failing if #365 is applied as well, but will
still fail with ONLY #365 applied (IOW, both are needed)

 - poc1  #335 - CVE-2022-43240
 - poc3  #337 - CVE-2022-43235
 - poc5   #339 - CVE-2022-43423
 - poc9-1,poc9-2, poc9-4  #343 - CVE-2022-43236
 - poc14  #348 - CVE-2022-43253
 - poc15  #349 - CVE-2022-43248
 - poc17-1, poc17-2  #351
 - poc18 #352 - CVE-2022-43245

Gbp-Pq: Name use_sps_from_the_image.patch

[PATCH] Try to mitigate asan failures.

See #345 for my analysis and details…

(This PR is just for discussion.)

(The CVE references are obtained from the Debian security tracker,
which links the issues.)

This makes the following POCs stop failing:

- poc3 (#337)
- poc7-1 (#341) CVE-2022-43239 (note: does NOT fix poc7-2)
- poc8-2, poc8-3, poc8-4 (#342) CVE-2022-43244   (note: does NOT fix poc8-1)
- poc11-1, poc11-2 (#345) CVE-2022-43249
- poc12 (#346)
- poc13 (#347) CVE-2022-43252
- poc16 (#350)

Gbp-Pq: Name reject_reference_pics_from_different_sps.patch

[PATCH] fix reading invalid images where shdr references are NULL in part of the image (#302)

Gbp-Pq: Name CVE-2021-36411.patch

[PATCH] fix MC with HDR chroma, but SDR luma (#301)

Gbp-Pq: Name CVE-2021-36410.patch

[PATCH] fix assertion when reading invalid scaling_list (#300)

Gbp-Pq: Name CVE-2021-36409.patch

[PATCH] fix streams where SPS image size changes without refreshing PPS (#299)

Gbp-Pq: Name CVE-2021-36408.patch

[PATCH] fix check for valid PPS idx (#298)

Gbp-Pq: Name CVE-2021-35452.patch

[PATCH] return error when PCM bits parameter exceeds pixel depth (#225)

Gbp-Pq: Name CVE-2020-21599.patch

fix invalid memory access after unavailable reference frame insertion

Origin: https://github.com/strukturag/libde265/commit/ee8e09a7f6f65b7c409c7801ad64918a2925ed9b
Reviewed-by: Tobias Frost <tobi@debian.org>
Last-Update: 2023-01-24 <YYYY-MM-DD, last update of the meta-information, optional>

Needed to avoid asan errors for the version at hand, otherwise the crash even
happens before the pocs triggers.
Last-Update: 2023-01-24 <YYYY-MM-DD, last update of the meta-information, optional>
Gbp-Pq: Name fix-invalid-memory-access.patch

Replace deprecated FFmpeg API

Last-Update: <2015-11-02>

Gbp-Pq: Name ffmpeg_2.9.patch

Disable building of some internal tools that no longer link

because internal symbols are not exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.3-1+deb10u3) buster-security; urgency=medium

  * Non-maintainer upload by the LTS Security Team.
  * Source-only upload. (Last upload was accidentially a binary-upload)

[dgit import unpatched libde265 1.0.3-1+deb10u3]

Import libde265_1.0.3-1+deb10u3.debian.tar.xz

[dgit import tarball libde265 1.0.3-1+deb10u3 libde265_1.0.3-1+deb10u3.debian.tar.xz]

Merge version 1.0.3-1+rpi1 and 1.0.3-1+deb10u1 to produce 1.0.3-1+rpi1+deb10u1

Merge libde265 (1.0.3-1+deb10u1) import into refs/heads/workingbranch

[PATCH] fix reading invalid images where shdr references are NULL in part of the image (#302)

Gbp-Pq: Name CVE-2021-36411.patch

[PATCH] fix MC with HDR chroma, but SDR luma (#301)

Gbp-Pq: Name CVE-2021-36410.patch

[PATCH] fix assertion when reading invalid scaling_list (#300)

Gbp-Pq: Name CVE-2021-36409.patch

[PATCH] fix streams where SPS image size changes without refreshing PPS (#299)

Gbp-Pq: Name CVE-2021-36408.patch

[PATCH] fix check for valid PPS idx (#298)

Gbp-Pq: Name CVE-2021-35452.patch

[PATCH] return error when PCM bits parameter exceeds pixel depth (#225)

Gbp-Pq: Name CVE-2020-21599.patch

Replace deprecated FFmpeg API

Last-Update: <2015-11-02>

Gbp-Pq: Name ffmpeg_2.9.patch

Disable building of some internal tools that no longer link

because internal symbols are not exported.

Gbp-Pq: Name disable_tools.patch

Only export symbols defined in the decoder API.

The encoder API is not final yet, so upstream exports all symbols to make
development easier. For packaging we only want to expose the public API.

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.3-1+deb10u1) buster-security; urgency=medium

  * Non-maintainer upload by the LTS Security Team.
  * Cherry-pick upstream patches for:
    - CVE-2020-21599 (See #1014999)
    - CVE-2021-35452, CVE-2021-36408, CVE-2021-36409, CVE-2021-36410 and
      CVE-2021-36411 (Closes: 1014977)

[dgit import unpatched libde265 1.0.3-1+deb10u1]

Import libde265_1.0.3-1+deb10u1.debian.tar.xz

[dgit import tarball libde265 1.0.3-1+deb10u1 libde265_1.0.3-1+deb10u1.debian.tar.xz]

Merge version 1.0.2-2+rpi1 and 1.0.3-1 to produce 1.0.3-1+rpi1

Import libde265_1.0.3.orig.tar.gz

[dgit import orig libde265_1.0.3.orig.tar.gz]

Merge libde265 (1.0.3-1) import into refs/heads/workingbranch

ffmpeg_2.9

Gbp-Pq: Name ffmpeg_2.9.patch

disable_tools

Gbp-Pq: Name disable_tools.patch

only_export_decoder_api

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.3-1) unstable; urgency=medium

  [ Ondřej Nový ]
  * d/copyright: Use https protocol in Format field
  * d/control: Set Vcs-* to salsa.debian.org

  [ Felipe Sateler ]
  * Change maintainer address to debian-multimedia@lists.debian.org

  [ Joachim Bauch ]
  * Imported Upstream version 1.0.3
  * Update patches for new upstream version.
  * Update symbols for new upstream version.
  * Update standards version and switch to debhelper 10.

[dgit import unpatched libde265 1.0.3-1]

Import libde265_1.0.3-1.debian.tar.xz

[dgit import tarball libde265 1.0.3-1 libde265_1.0.3-1.debian.tar.xz]

Merge libde265 (1.0.2-2+rpi1) import into refs/heads/workingbranch

Merge libde265 (1.0.2-2) import into refs/heads/workingbranch

disable-neon

Gbp-Pq: Name disable-neon.patch

ffmpeg_2.9

Gbp-Pq: Name ffmpeg_2.9.patch

disable_tools

Gbp-Pq: Name disable_tools.patch

only_export_decoder_api

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.2-2+rpi1) stretch-staging; urgency=medium

  [changes brought forward from 1.0.2-1+rpi1 by Peter Michael Green <plugwash@raspbian.org> at Sun, 04 Oct 2015 21:44:10 +0000]
  * Disable neon.

[dgit import unpatched libde265 1.0.2-2+rpi1]

Import libde265_1.0.2-2+rpi1.debian.tar.xz

[dgit import tarball libde265 1.0.2-2+rpi1 libde265_1.0.2-2+rpi1.debian.tar.xz]

ffmpeg_2.9

Gbp-Pq: Name ffmpeg_2.9.patch

disable_tools

Gbp-Pq: Name disable_tools.patch

only_export_decoder_api

Gbp-Pq: Name only_export_decoder_api.patch

libde265 (1.0.2-2) unstable; urgency=low

  [ Joachim Bauch ]
  * Added patch by Andreas Cadhalpun to fix compilation with FFmpeg 2.9
    (Closes: #803834)
  * Updated symbols file for new C++11 symbols.

  [ Sebastian Ramacher ]
  * Migrate to automatic dbg packages.
  * debian/control: Remove some unnecessary Build-Depends.

[dgit import unpatched libde265 1.0.2-2]

Import libde265_1.0.2-2.debian.tar.xz

[dgit import tarball libde265 1.0.2-2 libde265_1.0.2-2.debian.tar.xz]

Import libde265_1.0.2.orig.tar.gz

[dgit import orig libde265_1.0.2.orig.tar.gz]

libde265 (0.9-1) unstable; urgency=low

  * Updated symbols to make all "std::vector" symbols optional.
  * Imported Upstream version 0.9
  * Removed deprecated patch to update symbols visibility. Changes were
    applied upstream.
  * Upstream supports compiling against Qt5, prefer that over Qt4.
  * Added new symbols from new upstream release.

[dgit import unpatched libde265 0.9-1]

Import libde265_0.9.orig.tar.gz

[dgit import orig libde265_0.9.orig.tar.gz]

Import libde265_0.9-1.debian.tar.xz

[dgit import tarball libde265 0.9-1 libde265_0.9-1.debian.tar.xz]