Ubuntu
cmark-gfm package

auto-synced transition to 0.29.0.gfm.2-1 left various packages behind broken

Bug #1958235 reported by Christian Ehrhardt 
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cmark-gfm (Ubuntu)
Fix Released
Critical
Unassigned
gitit (Ubuntu)
Fix Released
Undecided
Unassigned
pandoc (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I've seen that pandoc fails, example:

root@j:~# pandoc
pandoc: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0: cannot open shared object file: No such file or directory

That made me wonder about this dependency and I found others like gitit:

root@j:~# gitit
gitit: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0: cannot open shared object file: No such file or directory

Turns out that cmark-gfm had a transition but all deps had bad dependencies
From:
 cmark-gfm | 0.29.0.gfm.0-6 | impish/universe | source, amd64, arm64, armhf, ppc64el, riscv64, s390x
To:
 cmark-gfm | 0.29.0.gfm.2-1 | jammy/universe | source, amd64, arm64, armhf, ppc64el, riscv64, s390x

The generated depends lines are
Depends: ..., libcmark-gfm0 (>= 0.29.0.gfm.0), ...

And >= 0.29.0.gfm.0 the new >= 0.29.0.gfm.2 is.

But IMHO this should have been a real transition libcmark-gfm0 -> libcmark-gfm2 at least as far as I've checked.

----

You might think "lets just rebuild them and be done with it", but to make things worse some can't even be rebuilt.
- gitit - works picking up libcmark-gfm0 (>= 0.29.0.gfm.2)
- pandoc - FTBFS due to pandoc failing (cyclical)

Maybe there are more in this list:
$ reverse-depends --release jammy libcmark-gfm0
Reverse-Depends
* cmark-gfm
* gitit
* libcmark-gfm-dev
* libcmark-gfm-extensions0
* libghc-cmark-gfm-dev
* libghc-gitit-dev
* libghc-hakyll-dev
* libghc-pandoc-citeproc-dev
* libghc-pandoc-dev
* pandoc
* pandoc-citeproc
* patat [amd64 arm64 armhf ppc64el]

---

Right now this is "only" broken in proposed:
root@j:~# apt-cache policy libcmark-gfm0
libcmark-gfm0:
  Installed: 0.29.0.gfm.2-1
  Candidate: 0.29.0.gfm.2-1
  Version table:
 *** 0.29.0.gfm.2-1 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/universe amd64 Packages
        100 /var/lib/dpkg/status
     0.29.0.gfm.0-6 500
        500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packag

But it breaks any build in proposed using any of the above tools, and pandoc is used here and there for markup conversion - those are all FTBFS now.

---

That seems to be just aas bad in Debian
Here in a sid container:

root@d10-sid:~# apt install pandoc
...
Get:1 http://deb.debian.org/debian sid/main amd64 libcmark-gfm0 amd64 0.29.0.gfm.2-1 [118 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 libcmark-gfm-extensions0 amd64 0.29.0.gfm.2-1 [46.8 kB]
Get:3 http://deb.debian.org/debian sid/main amd64 pandoc-data all 2.9.2.1-2 [377 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 pandoc amd64 2.9.2.1-2 [18.5 MB]

root@d10-sid:~# pandoc
pandoc: error while loading shared libraries: libcmark-gfm.so.0.29.0.gfm.0: cannot open shared object file: No such file or directory

---

TBH: I see no bugs in Debian nor in Ubuntu about it yet, so I might miss a major puzzle piece here.

---

Suggestion:
1. let us remove the bad cmark-gfm from jammy-proposed (fixing all current issues)
2. IMHO this is bad for Debian too, can we stop it there (2 days to move to testing according to https://tracker.debian.org/pkg/cmark-gfm)
3. someone report or work with Debian on a fix to get this right

I'll add bug tasks for those packages affected to show up in mismatches, but the failure&fix most likely is in cmark-gfm

Christian Ehrhardt  (paelzer)
tags: added: update-excuse
Revision history for this message
Utkarsh Gupta (utkarsh) wrote :

Yep, given I am on +1, I'll try to get this handled and sorted. I've asked the AA to process the removal of cmark-gfm. RAOF is looking into it. Raising the severity to high to reflect the situation.

Changed in cmark-gfm (Ubuntu):
importance: Undecided → Critical
status: New → Confirmed
Revision history for this message
Chris Halse Rogers (raof) wrote :

Huh.

Looks like cmark-gfm has already migrated out of jammy-proposed. I don't think we can roll back anymore, and will need to go forward instead.

I think the way forward would be to upload a 0.29.0.gfm.2.really.0.29.0.gfm.0-like package containing the old package, to build a working libcmark-gfm0, and *then* upload (or sync) a package with a proper transition.

Maybe the unbreaking package should be versioned 0.29.0.gfm.2-1ubuntu.really.0.29.0.gfm.0 so that versioning can stay in sync with a fixed Debian package?

Revision history for this message
Utkarsh Gupta (utkarsh) wrote :

Okay, thank you, Chris. I've uploaded cmark-gfm/0.29.0.gfm.2-1ubuntu.really.0.29.0.gfm.0 to fix this. Let's see how this one goes.

Revision history for this message
Utkarsh Gupta (utkarsh) wrote :

But it didn't make it through. Because "file cmark-gfm_0.29.0.gfm.2.orig.tar.gz already exists in Primary Archive for Ubuntu, but uploaded version has different contents."

I've asked on #ubuntu-release for further help. But by the looks of it, I think one of the AA might have to drop the package from Jammy and copy the one in Impish to Jammy. That should fix everything and avoid the weird version schema. :)

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

You need to keep the tarball (derived by the front of the version) identical.
The following should do it:
https://code.launchpad.net/~paelzer/ubuntu/+source/cmark-gfm/+git/cmark-gfm/+ref/back-to-former
It reverts the debian/* portion as-is and the code portion as new patch in d/p/
Thereby it should match the tarball and be accepted.

There were many versions suggested here and on IRC,
we need to make sure we do not jump back but also have the next debian version to be newer.

I worked out this one 0.29.0.gfm.2-1+really.0.29.0.gfm.0ubuntu1
$ dpkg --compare-versions "0.29.0.gfm.2-1" lt "0.29.0.gfm.2-1+really.0.29.0.gfm.0ubuntu1"
=> yes to we are newer
$ dpkg --compare-versions "0.29.0.gfm.2-2" lt "0.29.0.gfm.2-1+really.0.29.0.gfm.0ubuntu1"
=> no so an upgrade would happen on a later sync

I hope that helps to get this further, too bad it did migrate to -release before we could act :-/

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cmark-gfm - 0.29.0.gfm.2-1+really.0.29.0.gfm.0ubuntu1

---------------
cmark-gfm (0.29.0.gfm.2-1+really.0.29.0.gfm.0ubuntu1) jammy; urgency=medium

  * Revert to 0.29.0.gfm.0-6 for Jammy. (LP: #1958235)
    The new version, 0.29.0.gfm.2-1, is a SONAME bump
    and causes a regression in pandoc, pandoc-citeproc,
    patat, gitit, blogliterately, at least. Therefore,
    revert to the older version until this is fixed in
    Debian and then we can have this sync'd here again.
    (LP: #1958235)

 -- Utkarsh Gupta <email address hidden> Wed, 19 Jan 2022 05:38:01 +0530

Changed in cmark-gfm (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Utkarsh Gupta (utkarsh) wrote :

With the new cmark-gfm in, src:pandoc and src:gitit are now working fine as well! \o/

```
root@jtemp:~# gitit
Created repository in wikidata
Added Front Page.page to repository
Added Help.page to repository
Added Gitit User’s Guide.page to repository
Created static/css/custom.css
Created static/img/logo.png
Created templates/footer.st
^C
```

```
root@jtemp:~# pandoc
^C
```

Therefore, marking both as fix released. :D

Changed in gitit (Ubuntu):
status: New → Fix Released
Changed in pandoc (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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