Merge ~zhsj/ubuntu/+source/gobject-introspection:ubuntu/noble into ubuntu/+source/gobject-introspection:ubuntu/noble

Hi Shengjing,

While I understand that the practical effect are almost the same, could you please provide this fix as a cherry-pick on top of the version in Noble, rather than a wholesale backport? That's the standard way for SRUs, and makes it easier for observers to understand that it's a standard SRU, not an MRE or any other kind of exceptional process.

I don't get the idea when there is no difference. This is a targeted fix only. The only difference is the version string. I think you want something like 1.80.1-2ubuntu24.04.1. But compared to 1.80.1-3~ubuntu24.04.1, the latter makes clear that the fix has been proven to work in oracular. It can't be confused with MRE, since the upstream version is not changed. Besides, when people going to fix something in future, they can just start to look at version after 1.8.1-3 in oracular and cherry-pick commits.

Yes, your points are valid, but that's not how we do SRUs. We don't backport versions, we cherry-pick fixes, because we want to ensure we only get the bugfix, nothing else, in order to minimize regression potential. For instance, with your backport, something *could* actually go wrong, since you're adding a .gitignore file. That file could be buggy, and lead to unwanted files being included in the final upload.

The version number is a natural consequence of that process, not the endgoal. If I see an upload with -XubuntuY.Z that's indicative of that minimalistic process. OTOH, -X~ubuntuYY.ZZ is showing that something else happened.

> For instance, with your backport, something *could* actually go wrong, since you're adding a .gitignore file. That file could be buggy, and lead to unwanted files being included in the final upload.

IMO you should compare and review the source package when uploading. There will also be buggy gitignore files globally in your home directory.

So if the new version only has the targeted fixes, what the version number should be used when backporting (or you can call it cherry-pick) to stable release? I don't see it has been written down somewhere. Shall we do it to avoid confusion in future?

https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging is the standard way to do it.

> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging is the standard way to do it.

I mean it doesn't say if the change is like fast-forward thing.

> > https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
> is the standard way to do it.
>
> I mean it doesn't say if the change is like fast-forward thing.

There is no notion of fast forward in the general case.

What I'm expecting to happen is a single commit (well, two if you split out the changelog in proper git-ubuntu etiquette) based off ubuntu/noble-devel that contains the fix and *only* the fix. There should be no mention of the 1.80.1-2 and 3 releases, although it'd be polite to credit the Debian contributor in the changelog.