Bug#1034501: ITP: luametatex -- New generation processing Engine for ConTeXt
Package: wnpp Severity: wishlist Owner: Hilmar Preusse X-Debbugs-Cc: debian-de...@lists.debian.org I'm not fully sure about the final name of the source package. The OpenSuSE people name it texlive-context-bin, maybe I'll use a similar naming. * Package name: luametatex Version : 2.10.07 Upstream Contact: Hans Hagen * URL : https://github.com/contextgarden/luametatex * License : GPL, MIT/X Programming Lang: C, CWeb, C++ Description : New generation processing Engine for ConTeXt This is a follow up on the LuaTeX project. The source is considered part of the ConTeXt distribution and managed by the ConTeXt development team and the ConTeXt user group. That way we can guarantee that the engine and this TeX macro package work together as expected. The idea is that users can easily compile the source themselves and that way have a guaranteed long term (minimal) TeX based installation. Because the management scripts are in Lua, only one binary is needed to serve the ConTeXt distribution. In the source code we try to stay close to the ancestors, LuaTeX, pdfTeX, eTeX and TeX, but in the meantime due to additions there is quite some diverge. There are new primitives and submechanisms, there is more control over the inner workings, font handling is mostly delegated to Lua and there is no built-in backend. The code base is all-inclusive and has no (nor will have) dependencies on external libraries. - The TeX engine in this package will be (probably) the default processing engine of ConTeXt. The upcoming 2023 release of Context will hence depend on it. - I'm a member of the Debian TeX Task force, I'll maintain the package as a member of the team. As I'm not a DD, I'd a sponsor for the initial upload. -- sigmentation fault signature.asc Description: PGP signature
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Mon, 17 Apr 2023 at 03:09, Roger Shimizu wrote: > > Package: wnpp > Severity: wishlist > Owner: Roger Shimizu > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: linux-board-support-package-dragonboard845c > Version : 20190529180356-v4 > Upstream Author : Linaro > * URL : > https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware > * License : non-free > Description : Firmware for dragonboard845c / RB3 > > This package contains the binary firmware for GPU, USB, DSP hardware > coprocessors found on SDM845, which is the main SoC on the > Dragonboard 845c / RB3. Generally, I think there is some misunderstanding here. Most of the firmware has been pushed to linux-firmware already (where possible). You probably have some other intentions here. If so, please describe them. I took a glance at the package sources on salsa. So, let's go at this one by one. firmware-qcom-dragonboard845c.install: [0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845 This is the file that is only used by the _host_ when programming the device. As such, it should not be a part of the en-device firmware. It has no use for the RB3 itself. [0-9]*/aop.mbn lib/firmware/qcom/sdm845 Bootloader. It should not be a part of /lib/firmware/ [0-9]*/BTFM.bin lib/firmware/qcom/sdm845 This is the filesystem image with bluetooth firmware files. Relevant files are already part of the /lib/firmware/qca. If anything important is missing there, it should directly into [0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845 [0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845 [0-9]*/devcfg.mbn lib/firmware/qcom/sdm845 These three files are also used by the bootloader process, and as such they should not be a part of /lib/firmware. [0-9]*/dspso.bin lib/firmware/qcom/sdm845 This is probably the only important file for now. This is the filesystem image with the shared libraries and executable code for the DSPs when executing compute applications there. We were putting it to /lib/firmware/qcom/sdm845 and mounting it later, because it was easier to do so (if the image is not present in /lib/firmware, the rootfs can try mounting dspso parition). For proper Debian packaging the image should be unpacked to some agreed location. fastrpc daemons then should be taught about this location. [0-9]*/hyp.mbn lib/firmware/qcom/sdm845 [0-9]*/imagefv.elf lib/firmware/qcom/sdm845 [0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845 [0-9]*/sec.dat lib/firmware/qcom/sdm845 [0-9]*/storsec.mbn lib/firmware/qcom/sdm845 [0-9]*/tz.mbn lib/firmware/qcom/sdm845 [0-9]*/xbl.elf lib/firmware/qcom/sdm845 [0-9]*/xbl_config.elf lib/firmware/qcom/sdm845 [0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845 Again, mostly bootloader stuff. I highly doubt that /lib/firmware should be polluted with these files. renesas_usb_fw.mem lib/firmware So, this is the Renesas firmware, which gets copyrighted by Qualcomm. We noticed this some time ago (and the fact that the supplier of the firmware, Thundercomm, also pulled the file without having a clear origin). We have been trying to clear licensing terms for this file, however Renesas is unresponsive. Originally this file came from the author (Renesas) without proper license. Thus I do not believe it passes required checks by ftpmasters. linaro-abl/aosp/* lib/firmware/qcom/sdm845/abl-aosp linaro-abl/linux/* lib/firmware/qcom/sdm845/abl-linux I don't know what this is, but judging from the name (ABL) it also should not be part of /lib/firmware. Especially the AOSP file. Next package: network-manager-config-dragonboard845c.install debian/eth-mac-addr.conf usr/lib/NetworkManager/conf.d/ I do not think this should be a part of the firmware-qcom-dragonboard845c source package. It is not a firmware. > If you have any concerns, or you can offer co-maintenance of the package in > Debian, please let me know. Well, I'd like to understand your intentions with this package. Please feel free to ask any questions regarding these files or about packaging them. -- With best wishes Dmitry
Bug#1034496: ITP: linux-board-support-package-rb5 -- Firmware for RB5
On Mon, 17 Apr 2023 at 03:18, Roger Shimizu wrote: > > Package: wnpp > Severity: wishlist > Owner: Roger Shimizu > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: linux-board-support-package-rb5 > Version : 20210901-v6 > Upstream Author : Linaro > * URL : https://releases.linaro.org/96boards/rb5/qualcomm/firmware > * License : non-free > Description : Firmware for RB5 > > This package contains the binary firmware for the SM8250, which is the > main SoC on the Robotics RB5. As I wrote in the https://bugs.debian.org/1034495 discussion, most if not all firmware files relevant to the board are a part of the linux-firmware package already. If the intent is to provide additional files (e.g. bootloader), please describe your usecases and the intended layout. -- With best wishes Dmitry
Bug#1034507: ITP: torctl -- Redirect all traffic through tor network
Package: wnpp Severity: wishlist Owner: Danial Behzadi X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: torctl Version : 0.5.7 Upstream Contact: BlackArch * URL : https://github.com/BlackArch/torctl * License : GPL-3+ Programming Lang: Bash Description : Redirect all traffic through tor network Script to redirect all traffic through tor network including dns queries for anonymizing entire system.
Bug#1034360: ITP: supersonic -- A lightweight cross-platform desktop client for Subsonic music servers
retitle 1034360 RFP: supersonic -- A lightweight cross-platform desktop client for Subsonic music servers thanks The dependency tree on this is just too deep. Until Fyne, at least, is packaged, I'm not going to look at this. It should also be noted that Supersonic uses a *fork* of Fyne too... Some of the patches have been submitted upstream so hopefully that will resolve, but that also makes packaging this quite impractical. For now, I've made a Flatpak which is awaiting approval on Flathub: https://github.com/flathub/flathub/pull/4073
Bug#1034144: RFP: openai triton -- fast BPE tokeniser for use with OpenAI's models
Control: retitle -1 ITP: openai triton -- fast BPE tokeniser for use with OpenAI's models I decided to upload this package to experimental under the Debian Deep Learning team umbrella. Sadly it is uploaded without the swinx documentation, which I could not get to build. -- Happy hacking Petter Reinholdtsen
Processed: Re: Bug#1034144: RFP: openai triton -- fast BPE tokeniser for use with OpenAI's models
Processing control commands: > retitle -1 ITP: openai triton -- fast BPE tokeniser for use with OpenAI's > models Bug #1034144 [wnpp] RFP: triton -- fast BPE tokeniser for use with OpenAI's models Changed Bug title to 'ITP: openai triton -- fast BPE tokeniser for use with OpenAI's models' from 'RFP: triton -- fast BPE tokeniser for use with OpenAI's models'. -- 1034144: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034144 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034307: RFP: tiktoken -- fast BPE tokeniser for use with OpenAI's models
Control: retitle -1 ITP: tiktoken -- fast BPE tokeniser for use with OpenAI's models I've decided to upload this package to experimental under the umbrella of the Deep Learning Team. -- Happy hacking Petter Reinholdtsen
Processed: Re: Bug#1034307: RFP: tiktoken -- fast BPE tokeniser for use with OpenAI's models
Processing control commands: > retitle -1 ITP: tiktoken -- fast BPE tokeniser for use with OpenAI's models Bug #1034307 [wnpp] RFP: tiktoken -- fast BPE tokeniser for use with OpenAI's models Changed Bug title to 'ITP: tiktoken -- fast BPE tokeniser for use with OpenAI's models' from 'RFP: tiktoken -- fast BPE tokeniser for use with OpenAI's models'. -- 1034307: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034307 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034091: RFP: whisper -- Robust Speech Recognition via Large-Scale Weak Supervision
Control: retitle -1 ITP: whisper -- Robust Speech Recognition via Large-Scale Weak Supervision I have decided to upload this package to experimental under the unbrella of the Deep Learning Team. I suspect it should go into contrib because of the state of its neural network models. Not quite sure how to handle the models. Perhaps create a non-free package with one model, or simply ask people to download the model individually? -- Happy hacking Petter Reinholdtsen
Processed: Re: RFP: whisper -- Robust Speech Recognition via Large-Scale Weak Supervision
Processing control commands: > retitle -1 ITP: whisper -- Robust Speech Recognition via Large-Scale Weak > Supervision Bug #1034091 [wnpp] RFP: whisper -- Robust Speech Recognition via Large-Scale Weak Supervision Changed Bug title to 'ITP: whisper -- Robust Speech Recognition via Large-Scale Weak Supervision' from 'RFP: whisper -- Robust Speech Recognition via Large-Scale Weak Supervision'. -- 1034091: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034091 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034531: ITP: obs-scene-as-transition -- plugin for OBS Studio to use a Scene as a Transition
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho X-Debbugs-Cc: debian-de...@lists.debian.org, Andi Stone * Package name: obs-scene-as-transition Version : 1.1.0 Upstream Contact: Andi Stone * URL : https://obsproject.com/forum/resources/scene-as-transition.1704 * License : GPL-2 Programming Lang: C Description : plugin for OBS Studio to use a Scene as a Transition This plugin can be used to create all kinds of transitions. It is recommended to get the most out of this plugin that you use other powerful plugins such as obs-move-transition to create advanced movements. Is possible to make the transitions dynamic by passing information from other ways. An example would be putting a text source on the transition scene and having it updated with the name of the scene or game you are transitioning to. Some features: - Choose a scene to use as a transition. - Set the total transition duration. - Set a what point the scene changes (Time or Percentage). - Choose a filter to trigger on the transition scene when the transition starts.
Processed: O: gpsd -- Global Positioning System - daemon
Processing control commands: > affects -1 + src:gpsd Bug #1034532 [wnpp] O: gpsd -- Global Positioning System - daemon Added indication that 1034532 affects src:gpsd -- 1034532: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034532 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034532: O: gpsd -- Global Positioning System - daemon
Package: wnpp Severity: normal X-Debbugs-Cc: g...@packages.debian.org Control: affects -1 + src:gpsd Hi! I intend to orphan the gpsd package. While it was fun to work on the package back at the time when ESR was the lead developer, things have changed unfortunately. If you want to take over the maintenance of the package: - expect a hostile upstream, especially when you talk about distro requirements, systemd or similar things - expect words that will fail to pass any kind of code of conduct. - expect breaking API and ABI changes with every version. - expect scons as build system, which is a major source of PAIN in every imaginable body part. - you should have some knowledge about libraries, symbols, API/ABIs, building shared/static libs and similar things, you might need to be able to debug the build/usage of all these things, althouigh lately the scons stuff worked okayish most of the time. I'm happy to help to take over the maintenance of the package, guess I have a bit of in depth knowledge as I've fixed various bugs on the upstream side, too The package description is: The gpsd service daemon can monitor one or more GPS devices connected to a host computer, making all data on the location and movements of the sensors available to be queried on TCP port 2947. . With gpsd, multiple GPS client applications can share access to devices without contention or loss of data. Also, gpsd responds to queries with a format that is substantially easier to parse than the different standards emitted by GPS devices. . This also includes common tools ubxtool and gpsctl for device configuration of the local hardware as well as a ntpshmmon to check generated refclock data. Thanks, Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Processed: RFS: luametatex/2.10.07-1 [ITP] -- Next generation ConTeXt processing engine
Processing commands for cont...@bugs.debian.org: > block 1034501 by 1034546 Bug #1034501 [wnpp] ITP: luametatex -- New generation processing Engine for ConTeXt 1034501 was not blocked by any bugs. 1034501 was not blocking any bugs. Added blocking bug(s) of 1034501: 1034546 > End of message, stopping processing here. Please contact me if you need assistance. -- 1034501: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034501 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: RFS: torctl/0.5.7-1 [ITP] -- Redirect all traffic through tor network
Processing commands for cont...@bugs.debian.org: > block 1034507 by 1034544 Bug #1034507 [wnpp] ITP: torctl -- Redirect all traffic through tor network 1034507 was not blocked by any bugs. 1034507 was not blocking any bugs. Added blocking bug(s) of 1034507: 1034544 > End of message, stopping processing here. Please contact me if you need assistance. -- 1034507: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034507 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
Dear Dmitry, Thanks for your response! Very informative. And the ultimate goal is to have a debian-installer image. So this firmware upload is just the first step. Let me reply to you inline below. On Mon, Apr 17, 2023 at 3:15 AM Dmitry Baryshkov wrote: > > On Mon, 17 Apr 2023 at 03:09, Roger Shimizu wrote: > > > > Package: wnpp > > Severity: wishlist > > Owner: Roger Shimizu > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: linux-board-support-package-dragonboard845c > > Version : 20190529180356-v4 > > Upstream Author : Linaro > > * URL : > > https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware > > * License : non-free > > Description : Firmware for dragonboard845c / RB3 > > > > This package contains the binary firmware for GPU, USB, DSP hardware > > coprocessors found on SDM845, which is the main SoC on the > > Dragonboard 845c / RB3. > > Generally, I think there is some misunderstanding here. Most of the > firmware has been pushed to linux-firmware already (where possible). > You probably have some other intentions here. If so, please describe them. Thanks for the upstreaming work! I checked package firmware-qcom-soc [1], and found GPU / Audio DSP / Modem firmware is already there. [1] https://packages.debian.org/unstable/firmware-qcom-soc > I took a glance at the package sources on salsa. So, let's go at this > one by one. > > firmware-qcom-dragonboard845c.install: > > [0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845 > > This is the file that is only used by the _host_ when programming the > device. As such, it should not be a part of the en-device firmware. It > has no use for the RB3 itself. > > [0-9]*/aop.mbn lib/firmware/qcom/sdm845 > > Bootloader. It should not be a part of /lib/firmware/ Since my ultimate goal is to make an installer image, the bootloader part is necessary. Because we don't have the source code for this, and we have to flash this file to one partition of the UFS on the board in order to boot the system, we have to treat it as firmware. If you have a better idea for the path name, rather than /lib/firmware/, please let me know. > [0-9]*/BTFM.bin lib/firmware/qcom/sdm845 > > This is the filesystem image with bluetooth firmware files. Relevant > files are already part of the /lib/firmware/qca. If anything important > is missing there, it should directly into Good to know it's already upstreamed, and it's under qca folder. > [0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845 > [0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845 > [0-9]*/devcfg.mbn lib/firmware/qcom/sdm845 > > These three files are also used by the bootloader process, and as such > they should not be a part of /lib/firmware. > > [0-9]*/dspso.bin lib/firmware/qcom/sdm845 > > This is probably the only important file for now. This is the > filesystem image with the shared libraries and executable code for the > DSPs when executing compute applications there. > We were putting it to /lib/firmware/qcom/sdm845 and mounting it later, > because it was easier to do so (if the image is not present in > /lib/firmware, the rootfs can try mounting dspso parition). For proper > Debian packaging the image should be unpacked to some agreed location. > fastrpc daemons then should be taught about this location. Yes, we need to integrate this into the installer. > [0-9]*/hyp.mbn lib/firmware/qcom/sdm845 > [0-9]*/imagefv.elf lib/firmware/qcom/sdm845 > [0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845 > [0-9]*/sec.dat lib/firmware/qcom/sdm845 > [0-9]*/storsec.mbn lib/firmware/qcom/sdm845 > [0-9]*/tz.mbn lib/firmware/qcom/sdm845 > [0-9]*/xbl.elf lib/firmware/qcom/sdm845 > [0-9]*/xbl_config.elf lib/firmware/qcom/sdm845 > [0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845 > > Again, mostly bootloader stuff. I highly doubt that /lib/firmware > should be polluted with these files. > > renesas_usb_fw.mem lib/firmware > > So, this is the Renesas firmware, which gets copyrighted by Qualcomm. > We noticed this some time ago (and the fact that the supplier of the > firmware, Thundercomm, also pulled the file without having a clear > origin). We have been trying to clear licensing terms for this file, > however Renesas is unresponsive. Originally this file came from the > author (Renesas) without proper license. Thus I do not believe it > passes required checks by ftpmasters. If this is the issue, we can remove this blob. But basically, this is a non-free package, and if we can redistribute the file it should not be a problem. The file is on linaro archive for years for free download to anymore. And you informed Renesas about this, so if they don't agree with the redistribution, they will ask you to pull it off long time ago. > linaro-abl/aosp/* lib/firmware/qcom/sdm845/abl-aosp > linaro-abl/linux/* lib/firmware/qcom/sdm845/abl-linux > > I don't know what this is, but judging from the name (ABL) it also > should not be part of /lib/firmware. Especially the AOSP fil
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
18 апреля 2023 г. 05:35:00 GMT+03:00, Roger Shimizu пишет: >Dear Dmitry, > >Thanks for your response! >Very informative. > >And the ultimate goal is to have a debian-installer image. >So this firmware upload is just the first step. Thanks for the information. Short answer: please do not touch the partitions you don't have to. > >Let me reply to you inline below. > >On Mon, Apr 17, 2023 at 3:15 AM Dmitry Baryshkov > wrote: >> >> On Mon, 17 Apr 2023 at 03:09, Roger Shimizu wrote: >> > >> > Package: wnpp >> > Severity: wishlist >> > Owner: Roger Shimizu >> > X-Debbugs-Cc: debian-de...@lists.debian.org >> > >> > * Package name: linux-board-support-package-dragonboard845c >> > Version : 20190529180356-v4 >> > Upstream Author : Linaro >> > * URL : >> > https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware >> > * License : non-free >> > Description : Firmware for dragonboard845c / RB3 >> > >> > This package contains the binary firmware for GPU, USB, DSP hardware >> > coprocessors found on SDM845, which is the main SoC on the >> > Dragonboard 845c / RB3. >> >> Generally, I think there is some misunderstanding here. Most of the >> firmware has been pushed to linux-firmware already (where possible). >> You probably have some other intentions here. If so, please describe them. > >Thanks for the upstreaming work! >I checked package firmware-qcom-soc [1], and found GPU / Audio DSP / >Modem firmware is already there. > >[1] https://packages.debian.org/unstable/firmware-qcom-soc > >> I took a glance at the package sources on salsa. So, let's go at this >> one by one. >> >> firmware-qcom-dragonboard845c.install: >> >> [0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845 >> >> This is the file that is only used by the _host_ when programming the >> device. As such, it should not be a part of the en-device firmware. It >> has no use for the RB3 itself. >> >> [0-9]*/aop.mbn lib/firmware/qcom/sdm845 >> >> Bootloader. It should not be a part of /lib/firmware/ > >Since my ultimate goal is to make an installer image, the bootloader >part is necessary. >Because we don't have the source code for this, and we have to flash >this file to one >partition of the UFS on the board in order to boot the system, we have >to treat it as >firmware. Does Debian installer update the BIOS of your PC during installation? No. Is RB3 (or RB5) somehow different from your PC in this area? No. Please don't touch the system partitions. User might have some custom code there. They might have a customized bootloader. Last, but not least, updating the bootloader might brick the board, if power gets turned off at the improper time, leaving the user with the hardware requiring one to perform additional rescue process through QDL. > >If you have a better idea for the path name, rather than /lib/firmware/, >please let me know. > >> [0-9]*/BTFM.bin lib/firmware/qcom/sdm845 >> >> This is the filesystem image with bluetooth firmware files. Relevant >> files are already part of the /lib/firmware/qca. If anything important >> is missing there, it should directly into > >Good to know it's already upstreamed, and it's under qca folder. > >> [0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845 >> [0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845 >> [0-9]*/devcfg.mbn lib/firmware/qcom/sdm845 >> >> These three files are also used by the bootloader process, and as such >> they should not be a part of /lib/firmware. >> >> [0-9]*/dspso.bin lib/firmware/qcom/sdm845 >> >> This is probably the only important file for now. This is the >> filesystem image with the shared libraries and executable code for the >> DSPs when executing compute applications there. >> We were putting it to /lib/firmware/qcom/sdm845 and mounting it later, >> because it was easier to do so (if the image is not present in >> /lib/firmware, the rootfs can try mounting dspso parition). For proper >> Debian packaging the image should be unpacked to some agreed location. >> fastrpc daemons then should be taught about this location. > >Yes, we need to integrate this into the installer. No. This needs to be integrated into the system runtime, not into the installer. > >> [0-9]*/hyp.mbn lib/firmware/qcom/sdm845 >> [0-9]*/imagefv.elf lib/firmware/qcom/sdm845 >> [0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845 >> [0-9]*/sec.dat lib/firmware/qcom/sdm845 >> [0-9]*/storsec.mbn lib/firmware/qcom/sdm845 >> [0-9]*/tz.mbn lib/firmware/qcom/sdm845 >> [0-9]*/xbl.elf lib/firmware/qcom/sdm845 >> [0-9]*/xbl_config.elf lib/firmware/qcom/sdm845 >> [0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845 >> >> Again, mostly bootloader stuff. I highly doubt that /lib/firmware >> should be polluted with these files. >> >> renesas_usb_fw.mem lib/firmware >> >> So, this is the Renesas firmware, which gets copyrighted by Qualcomm. >> We noticed this some time ago (and the fact that the supplier of the >> firmware, Thundercomm, also pulled the file without having a clear >> orig
