Backport Intel Mutual Authentications - FCC Lock

Here is the debdiff with the upstream patch.

The attachment "libmbim_1.28.0-1~ubuntu20.04.2.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

I uploaded the modified version to my PPA:
https://launchpad.net/~pseudoc/+archive/ubuntu/ppa/+packages

You may install the libmbim from it:
sudo add-apt-repository ppa:pseudoc/ppa
sudo apt update
sudo apt install libmbim

refined debdiff (delete obsolete attachment)

The fix is available in newer Ubuntu serie, SRU uploaded to J serie now

Hi @seb128, this is not the same as Bug #1950282, this is for Fibocom L860-GL-16.

Talking to Atlas he misunderstood that the 'fix released' status was applying to the current Ubuntu serie and not jammy which is targetted there. Changing back to fixed for the current version

Sorry but apparently I was wrong there and misunderstood where the fix landed, it's not in the current version so we will need to also upload to mantic and lunar

I added tasks for Jammy, Lunar and Mantic (devel). I also took a look at the debdiff and you could also close this bug in the changelog via "LP: #2014954". Moreover, you could improve the patch DEP-3 headers and add the Bug-Ubuntu field with a link to this bug.

for lunar (delete obsolete attachment)

for mantic (delete obsolete attachment)

for jammy (delete obsolete attachment)

Thanks Lucas and Seb, I re-uploaded the debdiff patch file for theses 3 series.

An upload of libmbim to jammy-proposed has been rejected from the upload queue for the following reason: "Bug provides a newer SRU debdiff for this upload.".

This in your changelog is a Debian keyword
  Closes: #2014954
To work on launchpad that needs to be
  LP: #2014954

I hope that helps and gives you a few minor things to fix.

I feel too much out of my comfort zone to fully sponsor this anyway :-/
But I wondered about one more thing to ask you, given that you say this is "the feature itself might have bugs and glitches since it is a brand new one and is not widely tested by the laptop vendors" wouldn't you think it might be better to wait until upstream https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/tags tags 1.30 - then at least we'd have the testing of the developers there and all the code they tested it with.

@Lukasz, could you reconsider the rejection? The version which was in the 22.04 queue was correct, it's basically me who fixed the wrong bug reference to use a lp: syntax

Hi @Christian, thanks for the comment, I thought "Closes" and "LP" are the same thing.
The Lenovo wants to ship their new laptop products with "Fibocom L860-GL" (uses MBIM protocol) and needs this patch to do the FCC unlock. Their aim is that the SIM card can work properly once end user receives the device.

mantic: replace "Closes => LP"

lunar: replace "Closes => LP"

jammy: replace "Closes => LP"

Hi, I have some comments/questions.

## debdiffs

- The d/changelog entries target unstable and not Ubuntu releases
- The lunar version string is wrong, the suffix should be ubuntu0.1.
- The d/changelog entry is not clear.
  For example: it begins with "This service". Which service?
- Nit: when adding new patches it is nice to mention it in d/changelog:

 * d/p/intel-mutual-authentication.patch:
   upstream cherry-pick to enable the XYZ feature

## dep-3 headers

"Origin": please specify if "upstream" or "backport", see [1]. It may be "upstream" for some Ubuntu releases and "backport" for others, if the patch had to be modified to apply cleanly.

Also: normally the link is to the individual cherry-picked commit, not to the PR/MR.

"Applied-Upstream": not needed in this case I believe. AIUI that's for when the patch originates from Ubuntu/Debian and then has been applied upstream. In this case it's the other way around.

"Reviewed-by": that's specific to the Ubuntu patch, do not put upstream contributions there: they are not involved with the Ubuntu packaging.

## general questions

It is not clear to me (and may not be clear to the SRU team) what the actual impact of this issue. Is the hardware unusable without this feature? In other words: please improve the [Impact] section. Which issue will users encounter because of this bug? (What does it mean that the device is "secured" until unlocked?)

Like Christian mentioned, it would be better to wait for 1.30 to be tagged by upstream before going ahead with the backporting. Would the libmbim release schedule align with the hardware release dates?

[1] https://dep-team.pages.debian.net/deps/dep3/

Thanks you Paride for the comment with the detailed explanation. I will check the urgency of this bug later on.

By the time I proposed this bug, the WWAN card is totally unusable, but by far Lenovo have provide a workaround: https://pcsupport.lenovo.com/jp/en/products/laptops-and-netbooks/thinkpad-x-series-laptops/thinkpad-x1-yoga-7th-gen-type-21cd-21ce/21cd/downloads/driver-list/component?name=Networking%3A%20Wireless%20WAN&id=49B19606-BEF8-41DD-BE7F-95B570C212C8

So, to me, I think it is actually okay to wait for 1.30.

Unsubscribing ~ubuntu-sponsors; please re-subscribe once Paride's comments (from 21) are addressed. I'm not setting to incomplete as it appears a decision is pending regarding waiting for the 1.30 release and I'm not sure what the schedule on that is.

Hello All ,

May I know , if there is update of backporting this changes in Ubuntu 22.04 ?
As per above comment , it will be helpful if you can update in which Ubuntu version 1.30 will be released ?

Thank you !

Thanks & Regards,
Nitin Joshi