Automatic connection request for vivaldi : chromium-ffmpeg-115541

store-requests
1

Hi,

we’re in the process of preparing a release of new version of vivaldi and would like to request automatic connection for chromium-ffmpeg-115541

The command fixing our situation is:

snap connect vivaldi:chromium-ffmpeg-115541 chromium-ffmpeg:chromium-ffmpeg-115541

We’ve previously got granted the connection for chromium-ffmpeg-115016

Is the process here to ask again for automatic connection every time a name change happens? Every major revision of chromium is to be expected to have a new binary interface, requiring a name bump - so we would probably have to request this automatic connection for a new version every time we’re preparing a major release.

Is there, perhaps, a process in place to remove that need, granting further revisions of that interface automatically?

Thank you,

Filip from team Vivaldi

1 Like
2

+1 from me for auto-connect since this is identical to the previous use-case.

@nteodosio as the most recent uploader of this snap, can you shed any light on the subsequent question regarding future revisions / interfaces etc for the chromium-ffmpeg snap? Would you be willing to apply for a global auto-connect declaration for these interfaces to avoid each publisher having to manually request it for their snap? Thanks.

1 Like
3

@alexmurray, can you point me to where global auto-connection is defined? I thought global referred to “all possible consumer snaps of this interface” and not to “all possible interfaces this content snap ever creates”.

If I am right, then it would be vain to apply for it, since the slot names are changing with nearly every new release of the snap, which happens every so often, falling back to the original hindrance.

To be clear, right now the chromium-ffmpeg exposes

slots:
  chromium-ffmpeg-115016: # chromium 124.0.6367.118
  chromium-ffmpeg-115541: # chromium 125.0.6420.0

and each slot name will be every month replaced by other with a higher -version prefix.

Is the solution to create a fixed number of slots with fixed names and then apply for global auto-connection of each?

4

@nteodosio yes as you say, global auto-connect is about all possible consumers - not all possible interfaces/slots. So you would still need to apply for this each time you add a new content interface - BUT it would avoid each consumer having to then apply for it too. I expect you would still want to have per-version slots since I am guessing they are not ABI compatible (otherwise why have different slots in the first place?)

5

+1 from me as well for auto-connect of chromium-ffmpeg-115541 content interface to vivaldi snap. For the context, this request is similar to another request that’s been granted recently. Thanks

1 Like
6

Yes, I mean the names could be fixed even though the underlying software changes. So instead of explicitly changing the names to match each new Ffmpeg release, I could have

slots:
  chromium-ffmpeg-stable:
  chromium-ffmpeg-beta:
  etc...

and just apply once for global connection.

7

Question - isn’t the whole point of keeping the slot names ABI numbered, so that such a connection is stable even for arbitary/past releases?

How would naming -stable etc. work for any chromium-compatible browser version when the meaning of chromium-ffmpeg- changes due to stabilization of chromium, but the release schedule of such browser is different?

Do I understand right that what @alexmurray is proposing is applying for global autoconnect on the producer side (i.e. from the viewpoint of chromium-ffmpeg-XYZ releases) instead on the consumer side, while keeping the ABI version in slot name for stable connections? For us that seems like a good solution, since every one of the consumers now needs to apply for any new slot name.

Thank you,

Filip from team Vivaldi

8

Hi Fillip,

How would naming -stable etc. work for any chromium-compatible browser version when the meaning of chromium-ffmpeg- changes due to stabilization of chromium, but the release schedule of such browser is different?

The slots of chromium-ffmpeg do not and will not be following Chromium’s release schedule, but rather the consumers’ needs. I had Opera’s three snaps in mind when I gave *-{stable,beta,…} as examples — sorry that I didn’t explain my reasoning —, so that would be ‘their’ slots (Opera has three snaps following different Chromium releases). And then there would be “Vivaldi’s slot”. So, rewritten more clearly, I could maintain:

slots:
  opera-developer:
  opera-beta:
  opera-stable:
  vivaldi:

Then I don’t have to make a connection request for each new release of Ffmpeg the snap wants to expose, but rather only once in my life for each lot. And then I just update the actual base of the slots every time the consumers request without updating the slot name.

9

In my opinion this would break dependency much too easily, since updating the consumer snap would not be an atomic process, so in preparations for new update, the ffmpeg package would have to change ABI for that particular slot name, breaking new installs in the time between that happening and browser update finally being done (or am I missing something?).

Would it be prohibitively space-consuming (or otherwise unfeasable) to contain all the library versions in separate directories of a unified slot (chromium-ffmpeg-unified or similar)? Consumers could then specify the library path for the right lib inside their snap (f.ex. by using an ENV variable when doing the library setup) without the need of the automatic connection request process being ran on either side more than once (it would just be one chromium-ffmpeg snap containing multiple versions of the library).

ex:

/lib/ffmpeg-115016/ffmpeg.so
/lib/ffmpeg-115541/ffmpeg.so

A new version would just add the library into another versioned directory.

I see no need to version the slots, thus also no need to re-apply for autoconnection on either side with this approach.

10

That is a very nice solution. Let’s go with it.

1 Like
11

The proposed solution is in the beta channel, can you please give it a try? This is the plug you’d want:

plugs:
  chromium-ffmpeg:
    interface: content
    target: $SNAP/c
    default-provider: chromium-ffmpeg

Then you can use $SNAP/c/chromium-ffmpeg/$VERSION/libffmpeg.so. You can check how the test snap is doing it too.

12

From experimentation I observe that opera does auto-connect to any chromium-ffmpeg slot, regardless of whether it is new or not, and there has not been an auto-connection request from Opera (and certainly not from me on chromium-ffmpeg either) to auto-connect those new slots — the last one I found was in 2019.

@alexmurray, do you understand what is going on? Why would these repeated auto-connection requests be needed for Vivaldi but not for Opera?

1 Like
13

The opera snap has the following declaration for the content interface (note I have extracted just the bit which is relevant for the chromium-ffmpeg snap which has snap id XXzVIXswXKHqlUATPqGCj2w2l7BxosS8)

{
  "allow-auto-connection": [
    {
      "plug-attributes": {
        "content": "$SLOT(content)"
      },
      "slot-snap-id": [
        "XXzVIXswXKHqlUATPqGCj2w2l7BxosS8"
      ]
    }
}

Which essentially says to snapd, auto-connect any content interface slot on the snap with id XXzVIXswXKHqlUATPqGCj2w2l7BxosS8 which has the same content attribute as the plug - in this case, the relevant plug in the opera snap as per the most recent upload to the store is:

  chromium-ffmpeg-115541:
    interface: content
    target: $SNAP
    default-provider: chromium-ffmpeg

My recollection is since this plug declaration in the opera snap doesn’t explicitly define the content attribute it is inherited from the name of the interface. So in effect, this should auto-connect the content interface named chromium-ffmpeg-115541 on the chromium-ffmpeg snap.

Now for vivaldi we instead see it has the following declaration:

{
  "allow-auto-connection": [
    {
      "plug-attributes": {
        "content": "$SLOT(content)"
      },
      "slot-attributes": {
        "content": "chromium-ffmpeg-115016"
      },
      "slot-snap-id": [
        "XXzVIXswXKHqlUATPqGCj2w2l7BxosS8"
      ]
    }
}

Note the additional slot-attributes part of this declaration which restricts this to just the slot with the content attribute of chromium-ffmpeg-115016 - so it will only auto-connect to this slot on the chromium-ffmpeg snap.

Then if we look at the current snap yaml of the most recent upload of the vivaldi snap it has the following relevant plug:

  chromium-ffmpeg-115541:
    interface: content
    target: $SNAP
    default-provider: chromium-ffmpeg

We see that we have a mismatch between the declaration (which is scoped only to the slot chromium-ffmpeg-115016) and the snap yaml plug (chromium-ffmpeg-115541). We can fix this by removing the slot-attribute constraint on the snap declaration for vivaldi to make it the same as the one for opera. I have just done this which should hopefully resolve this issue. Please let me know though if you want us to do something different here. Hopefully this should then also be more future proof if the chromium-ffmpeg snap adds any further content slots and these browser snaps get updated to use those, since they should still auto-connect.

1 Like
14

Really helpful investigation and best case scenario solution, thank you very much!

1 Like
15

Thank you, this is the best case scenario, as we can keep the workflow intact on all sides.

16

Hey @vivaldi @nteodosio If I understood it correctly, the problem is solved now and no further action is required, right?

17

Right and, for 20 characters limit, correct too!