1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.BOOT

  • Re: Accepted protection-domain-mapper 1.0-6 (source amd64) into unstabl

    From Cyril Brulebois@21:1/5 to All on Tue Feb 4 00:20:01 2025
    Hi,

    Debian FTP Masters <ftpmaster@ftp-master.debian.org> (2025-02-03):
    Source: protection-domain-mapper
    Binary: protection-domain-mapper protection-domain-mapper-dbgsym protection-domain-mapper-udeb
    Architecture: source amd64
    Version: 1.0-6
    Distribution: unstable
    Urgency: medium
    Maintainer: DebianOnMobile Maintainers <debian-on-mobile-maintainers@alioth-lists.debian.net>
    Changed-By: Arnaud Ferraris <aferraris@debian.org>
    Description:
    protection-domain-mapper - Qualcomm Protection Domain mapper service
    protection-domain-mapper-udeb - Qualcomm Protection Domain mapper service (udeb)
    Changes:
    protection-domain-mapper (1.0-6) unstable; urgency=medium
    .
    * debian: update references to upstream URL.
    This project is now part of the `linux-msm` group on GitHub, and its
    main maintainer is now Konrad Dybcio. While at it, bump
    Standards-Version as no other change is required.
    * debian: add udeb package.
    This makes it possible to include this package in debian-installer
    images, allowing users to use remote processors (e.g. WiFi) when running
    on Qualcomm-based hardware.

    It's customary to let debian-boot@ know when adding some udeb. And it's
    not installable anyway, due to the dependency on libqrtr1. I see that
    other source package is in NEW, and a rebuild might eventually solve
    that, but same comment regarding the udeb addition.


    Cheers,
    --
    Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
    D-I release manager -- Release team member -- Freelance Consultant

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmehTYIACgkQ/5FK8MKz VSCLRBAAwzYIFku5oDhzJwmvBkhDva8ZCd52L47xCs/tI/IaLU/guI3oCZ6QozJm QQ8v0pZ+mr+cf/Tv+eO7ccvRyZijY4V4MmQA+bVOG4NgN47Zs7PxQurWTrWnHzF6 8TchBf5suwooxxOGHum1TmpwbAM+LDIulbtOS4FMFkklsMrXdy1BRHelzwvIZ5ps el4Y9ifNEizBZ0yXxFQxbFp5dkV7YI7P7W9ASMVy0ojuPxJFE16HvHtADiFLQRRc c9Mb2z5HJ0I9TGc4qPFmKruRiT/Tem8E0XfEPujimaLj8pp8HcxBrdZ3YGS9NDZR +u2xHun+/PjU16YeD9mxyndeMe4+44xzbOVTMNm9anuXzqZh8G5QaCuDf90AzMyt wZmzYNUQzfOmZeJrZpq5NXNMpFKhHw9zBQ+Qaj+UstlZIvd5xpUpVd/hBgNVV0fP b6ymEl/fnuM0npYJDdYEoKQd8J52wCDJVavgIz7/vsl+LIpfRbEC3APrwdvqeC4x 8flwlBvwMXY01kn1hH2YaGkuaxp52/YY/VBBoPh+apJH1lWYOq1qLcVsXoAfB1vX XQlWGMZ6p5M1Lzok+M05PfHtyu0IbnMMaijgwpD2HV2cqIpoxr+5I2JaDQhMDhij QFp+ZvIQJ5WDp+9fExVoiB4SBb/4ssYF60Y/fJbbQmSM1tsI5lE=
    =SUAW
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    *
  • From Cyril Brulebois@21:1/5 to All on Tue Feb 4 11:20:01 2025
    Hi Arnaud,

    Arnaud Ferraris <aferraris@debian.org> (2025-02-04):
    My apologies for not posting to debian-boot@, I would have expected
    such information to be available either in the policy or developer's reference but couldn't find much on the topic of udebs there.

    I'm happy to support the addition of such mention where you think you
    should have found it. As a general rule, if I'm going to operate in a particular Debian area, I tend to put the relevant team(s) in the loop
    anyway. :)

    Now let me give you a bit more context about this: here are the source packages generating udebs I've recently uploaded to NEW:
    * qrtr (generating udebs for libqrtr1 and qrtr-tools)
    * protection-domain-mapper
    * rmtfs
    * tqftpserv

    Please note the latter 3 depend on libqrtr1.

    OK, thanks. In the end, having packages around is not going to be
    sufficient anyway, they would need to be made available in this or that
    image, and integrated in some way (hardware detection → software dance
    at the right moment(s)), maybe it's already on your todo list?

    In any case, it'd be nice to have some kind of plan/picture on how
    things would fit together. It's not common (as far as I can remember) to
    have extra tools for hardware support (firmware packages being a rather separate topic).

    Those udebs were created per request (see #1076725 and #1076726) in
    order to allow installer support for Qualcomm-based devices,
    especially recent Snapdragon laptops.

    Alright, maybe #1091799 is an example of such hardware?


    Cheers,
    --
    Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
    D-I release manager -- Release team member -- Freelance Consultant

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmeh54wACgkQ/5FK8MKz VSDFMA//WxFA+9w2l7OeJ3+l9rYNd8EuOJ2ljnQdmt01ZPB0U9OdOuRe5hOZYw3L 9LuD6isG8ANcSmG1PeeFpqnBjyx/cNycEBlmPMf3VpoWIMdtTKaEaVqx4tZ3zL5l oxTg2Cy7kxE7KDovz4n1e9LAHql934TqI7Z0p54fwykdyoZA2WPT3JWw0lswygOL /lkf9ZzJrdYvJzdVtE6/qQpm9NHoYkJ6Byam4hODVD2bbq/gPd42/50X88x2bMHS St71BgN4ts/zhiIbUk74s0YVeP6LLJHSvsTeEuW9xCVHXBo8HNPrfzd1+PPwNLA7 Ec7juLQ78PPCh1Pj9Bx0AMhPe3ZA5e7KwqW7apfsNOJdWDV73TF0ukKETZNOL0bW Uh/SY6TizxthLcXO9GHEZC/EdXiX+oOaGDPEZTNmqlhijxiR5KRM8Ou7sa/mKXf5 95iTKCDalG/wNUowd/hLJLJHpT0coQTI0zG4HlRg79ucNRguUeQvZAX7+1V/W6Z+ 2N7ZByAHqT8TGV4+qrb86v01UZt+CiO0vnoAMBoXlSOJMGL1w7IzVE4akUOtIpZm fgq9Rg5N4w0G8YRn+E96MoKCJNPFocDzCENlD2hZBfCsTHasedzrbnLJvUInB/HV eKvxKJTil+WqEW606ovqpVHr1zJit0ewPvpPSpKlGl5I4aP0xzs=
    =aSD1
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    *
  • From Pascal Hambourg@21:1/5 to Cyril Brulebois on Tue Feb 4 20:50:01 2025
    Hi,

    On 04/02/2025 at 11:10, Cyril Brulebois wrote:
    Arnaud Ferraris <aferraris@debian.org> (2025-02-04):

    Those udebs were created per request (see #1076725 and #1076726) in
    order to allow installer support for Qualcomm-based devices,
    especially recent Snapdragon laptops.

    Alright, maybe #1091799 is an example of such hardware?

    Unlikely. The hardware featured in #1091799 is neither ARM nor recent:
    - Intel Core i3-3217U (x86, ~2012)
    - Atheros AR9485 (supported by ath9k since kernel 2.6.38 in 2010).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)