[SRU] biber 2.4 to xenial
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
biber (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Xenial |
Fix Released
|
Low
|
Unassigned |
Bug Description
Please SRU biber 2.4 to xenial.
[Impact]:
=======
Current biber version in xenial (2.3) is too old for texlive-
Backporting the most recent version (2.5) would still be a mistake since it requires a (>>= 2016) version of texlive-
The proper solution is to backport the 2.4-1 version as was seen in debian.
This has been verified to function properly in the aforementioned bug.
The bug has attracted a lot of attention with 68 people marked as affected as of June 13. It may meet the criteria for "High" severity since it "Has a severe impact on a small portion of Ubuntu users (estimated)" and "Prevents the application or any dependencies from functioning correctly at all".
[Changes]:
=======
2.4 (2016-03-01)
* Misc bug fixes
* There is now a 64-bit windows build built on windows 10
* Biblatexml datasources now support sourcemapping and have a schema
* New functionality in sourcemaps for creating new entries and
looping over specified fields.
* Sorting key used to sort names is now customisable. See
* Support for Zotero RDF/XML and Endnote removed. These were
experimental and messy.
https:/
[Test Case]:
=======
Mark off items in the checklist [X] as you test them, but please leave the checklist so that backporters can quickly evaluate the state of testing.
The original 2.4-1 version from debian/snapshot can be found here:
http://
The PPA build that was used for testing can be found here:
https:/
Probably, you can test-build the backport in your PPA with backportpackage:
$ backportpackage -u ppa:andrikos/ppa -s xenial -d xenial biber
* xenial:
[X] Package builds without modification
[X] biber installs cleanly and runs
[Regression Potential]:
========
The following reverse-
biber
-----
* science-typesetting
[ ] xenial (Reverse-
* texlive-
[X] xenial (Reverse-Breaks)
* med-typesetting
[ ] xenial (Reverse-Suggests)
description: | updated |
description: | updated |
description: | updated |
no longer affects: | xenial-backports |
summary: |
- [SRU] biber 2.4 + [SRU] biber 2.4 to xenial |
description: | updated |
Changed in biber (Ubuntu): | |
status: | Confirmed → Fix Released |
importance: | Undecided → Low |
Changed in biber (Ubuntu Xenial): | |
importance: | Undecided → Low |
tags: | added: upgrade-software-version |
"Because of the inherent stability risks in backporting packages, users do not get backported packages without some explicit action on their part. This generally makes backports an inappropriate avenue for fixing bugs. If a package in an Ubuntu release has a bug, it should be fixed either through the Security Update or the Stable Release Update process, as appropriate." [1]
I'll argue that this should be fixed through the regular SRU process, which I think often ends up being faster than backports anyway.
[1] https:/ /wiki.ubuntu. com/UbuntuBackp orts /wiki.ubuntu. com/StableRelea seUpdates
[2] https:/