[BPO] inkscape/1.1.1-3ubuntu1 from jammy

If you have a look at https://launchpad.net/ubuntu/+source/inkscape, you will find that 1.0-rc4 is currently stuck in release-proposed for groovy. Rest assured, this is being worked on.

Is it possible to have that SRU'ed as an additional Inkscape1.0 package to the LTS? Paralle to the normal Inkscape one?

mhh, in parallel... perhaps. but it would be _very_ odd.

Let me add the ~ubuntu-sru team to seek their input.

I suppose the options would be inkscape1.0 package conflicting/replacing(/providing?) with the regular inkscape, or be able to install it completely in parallel, though I'm not sure if the latter would work.

About uploading 1.0 as an update to 0.92.4, that won't be possible, too many changes including breaking changes to the command line that are easily going to break other packages.

Anyway, an update to the ~inkscape.dev/stable PPA will happen soon.

I think that conflicting/replacing would be fine. Focal will be around for a long, long time and 1.0 had a very bad timing being released so close after Focal.

Status changed to 'Confirmed' because the bug affects multiple users.

I think the best solution for focal would be to upload new inkscape release to focal-backports repository

The backport project is mostly dead, finding somebody to approve uploads is already tricky enough, the idea that I would need to chase people down for any needed update already scares me.

Someone tried to backport Inkscape 1.0-1 package to Ubuntu 20.04 (Focal)?
Debhelper 13 is not available in 20.04, it would be nice to have PPA with backported Inkscape 1.0 for testing.

here's the official upstream PPA that has 1.0: https://launchpad.net/~inkscape.dev/+archive/ubuntu/stable?field.series_filter=focal

This bug was fixed in the package inkscape - 1.0-1

---------------
inkscape (1.0-1) unstable; urgency=medium

  [ Mattia Rizzolo ]
  * New upstream version 1.0. LP: #1876996
    https://wiki.inkscape.org/wiki/index.php/Release_notes/1.0
    https://inkscape.org/release/inkscape-1.0/
    https://inkscape.org/news/2020/05/04/introducing-inkscape-10/
  * d/watch: Update to point at the new source archive.
  * Update Marc Jeanmougin's upstream gpg key.
  * Refresh patches.
  * Bump debhelper compat level to 13.

  [ Gianfranco Costamagna ]
  * Increase test timeout to 3 minutes instead of 1, to avoid failures when
    a slow machine runs tests (such as riscv64 that is emulated in Ubuntu).

 -- Mattia Rizzolo <email address hidden> Thu, 07 May 2020 20:57:39 +0200

Now that the BPO process has been renewed I'm going to follow through it (also, the SRU team never answered here, proof that they only look at bugs when uploads get into the queue…).

Although, I'm currently quite busy, so it'll take a bit of time.

I'm uploading now version 1.1.1-3ubuntu1~bpo20.04.1 to focal-backports, so that the team can review it.

It looks like the i386 arch fails to build due to missing dep on 'libgtkspell3-3-dev':
https://launchpad.net/~ddstreet/+archive/ubuntu/backport/+build/23139572

I'm not sure why i386 is missing in focal for that package; it seems like it's available both before and after focal, but the specific version in focal doesn't have it:
https://launchpad.net/ubuntu/+source/gtkspell3/3.0.10-1

can you look into that before we approve the backport? Possibly there should be a no-change rebuild of gtkspell3 in focal to pick up that i386 build?

meh, I didn't notice that, thank you.

Looking at the germinate-output file, it looks like gtkspell3 is included in the seed starting with groovy only because of it being a build-dep of inkscape (it's a new build-dep starting with inkscape 1.x, focal has 0.92.x).
This also means that a no-change rebuild wouldn't help, it would first need a manual addition to the i386.focal seed, which would be a pain to do. Plus gtkspell3's version is the same from focal all the way to jammy, so I'd need to SRU them all...

Honestly, in this case I would propose to just ignore that matter, and just say that inkscape/focal-backport will not be available in i386.

Personally, I actually find no reason for inkscape to be in the i386 seed (it's there only as a build-dep of a i386-only package), and I'm actually working (more or less, it's a plan) to drop it from there.

It looks like the build does have checks to set WITH_GSPELL off if the lib isn't available so the d/control could maybe just have [!i386] added to the libgtkspell3-3-dev depends? It looks like it already has that restriction for the ragel dep.

Or, the Architecture could be changed to avoid i386; or as you said we can just ignore the i386 build failures.

Any option is fine with me, as I agree it seems really unlikely anyone will want to use inkscape on a 32-bit system. Feel free to reupload with arch adjustment, or also feel free to accept the current upload (or let me know and I can accept it).

If possible I'd prefer to avoid an extra bpo diff just for this, so I'd rather accept it as it is.

(Also, ragel is fine to skip because it doesn't change anything in practice, it only used to rebuild something that is otherwise pre-compiled in the tarball; whereas disabling gspell would effectively change the feature set, something that I'd dislike to see done across architectures).

With your ACK I'm then going to accept my own upload, thank you for the through review!

> With your ACK I'm then going to accept my own upload

yep fine with me, thanks!