Re: Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters
On Thu, 2022-01-13 at 20:54 +, John Scott wrote: > You might like to have a look at this mail from Ben Hutchings: > https://lists.debian.org/msgid-search/179d6d32466dd13962a3aab251c45242fbf2d8ae.ca...@decadent.org.uk > The reason that none of the other Wi-Fi firmware packages have them is > because they're all non-free (with the exception of ath9k_htc). Thanks for the link, I'm not subscribed to that list. Makes sense. > I wasn't sure if there was any established convention; my thread "Naming > convention for udebs: -udeb/-installer suffix" didn't garner any > pertinent responses. I've switched the name though. I did a search of a Debian mirror filesystem and found that only the linux and linux-signed-* source packages use the -di suffix, most use the -udeb suffix. The -installer suffix seems to be used only for udeb packages when the source package has the -installer suffix too, such as bootloader installers like grub-installer, with a few exceptions for other udebs that install things. I suggest using the -udeb suffix. > These are all good catches, I'm working on incorporating them and doing > a slow and careful review. Recently on another project I noticed an upstream commit that added copyright information in the middle of a file alongside the functions that were copied from elsewhere. This sort of thing is hard to notice during the manual review of file headers I usually do using mc (after enabling the preview pane and arrow keys for navigation), but some of the copyright review tools might be helpful. I actually detected the list.h LGPL license using debmake -k (as run by check-all-the-things). Apparently the best option is ScanCode but that isn't in Debian yet. https://wiki.debian.org/CopyrightReviewTools > I think you're mistaken here, you should take a look at > /usr/share/dpkg/buildopts.mk which I include via an include directive in > debian/rules. Basically, DEB_BUILD_OPTION_PARALLEL is a helper macro for > the value of parallel from DEB_BUILD_OPTIONS; these are one and the > same. I see, I wasn't aware of this snippet/variable. > That's true. My intent was that, since it's a hidden directory, it would > help remind one that that directory gets created. It seems to've only > caused confusion, so I'll pull it. That seems reasonable if you want to keep it. Maybe add a comment. > Indeed, the documentation is rather old and terse and doesn't address > this issue. I'll probably ask the Reportbug folks and send them a MR > updating the docs. Great. > > Please ask upstream to make a new release, it has been a very long time > > since the last one. > I will do after making some of the following important changes. Thanks. > > Please ask upstream to send FindUSB-1.0.cmake & libusb-zeropacket.diff > > to libusb upstream and then remove them from carl9170fw. > I will ask, but with all due respect, I think this is lower priority and > that I'll have limited ability to help them. Sure. TBH they don't appear to be used by carl9170fw so I'm not sure why they are in the source repository at all. > I do not have a grasp, let alone a good one, of CMake, so this may be a > challenge. The documentation for CMake is fairly comprehensive, until recently I had never touched CMake and didn't understand it but when I needed to figure it out I found it to be reasonable and well documented. > I actually think I'll do one better: I submitted upstream an AppStream > metadata file a while ago, and although they haven't responded to it > yet, perhaps my sending them other changes will get their attention. > AppStream metadata and Debian upstream metadata files have considerable > overlap, and in my personal opinion having good AppStream metadata makes > an upstream metadata file unnecessary, but I'm willing to entertain > arguments to the contrary. I haven't looked at AppStream but I got the feeling they had different audiences or purposes or tools looking at them. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Bug#1002617: RFS: carl9170fw/1.9.9-399-gcd480b9-1 [ITP] -- firmware for AR9170 USB wireless adapters
Control: tags -1 moreinfo Hi Paul, Thanks for your very detailed review of carl9170fw. I'm still making my changes to the package and will give you a poke and remove the moreinfo tag once I have an upload ready for re-review. > I don't think udebs are needed for firmware packages, none of the other > WiFi firmware packages in Debian have them. You might like to have a look at this mail from Ben Hutchings: https://lists.debian.org/msgid-search/179d6d32466dd13962a3aab251c45242fbf2d8ae.ca...@decadent.org.uk The reason that none of the other Wi-Fi firmware packages have them is because they're all non-free (with the exception of ath9k_htc). My understanding—which was most definitely not articulated by Ben—is that the Debian Installer has a mechanism for loading the (non-free) firmware from the ordinary .debs. Since the installer needs to have logic to look for non-free firmware on removable media at runtime anyway, that's quite a different situation to most that warrant udebs, where the udeb is a "built-in" of the installer. FYI, open-ath9k-htc-firmware is in NEW because my most recent upload likewise adds a udeb for it. > If the package is actually needed it should be named -udeb not -di, > since other udebs use -udeb. I wasn't sure if there was any established convention; my thread "Naming convention for udebs: -udeb/-installer suffix" didn't garner any pertinent responses. I've switched the name though. > Several files have missing/incorrect information in debian/copyright, > please do a full audit of the code looking for copyright/license info. > > * tools/include/list.h is LGPL > * tools/include/frame.h is partly from Linux, unknown copyright > * include/shared/eeprom.h also contains ISC code These are all good catches, I'm working on incorporating them and doing a slow and careful review. > DEB_BUILD_OPTION_PARALLEL doesn't appear to be a standard variable, > please switch to DEB_BUILD_OPTIONS=parallel=N instead, see Debian > Policy, section 4.9.1 and debhelper(7) and dpkg-buildpackage(1). I think you're mistaken here, you should take a look at /usr/share/dpkg/buildopts.mk which I include via an include directive in debian/rules. Basically, DEB_BUILD_OPTION_PARALLEL is a helper macro for the value of parallel from DEB_BUILD_OPTIONS; these are one and the same. There's a chance of the DEB_BUILD_OPTION_PARALLEL Makefile macro still being unset, so what this line does in my Makefile: DEB_BUILD_OPTION_PARALLEL ?= 1 is set it to 1 if it's not set in one's DEB_BUILD_OPTIONS. That way, calls like make -j$(DEB_BUILD_OPTION_PARALLEL) won't become make -j which would be very bad. > Some things that would be nice to fix at some stage: > > Nothing in debian/rules references .config so you can drop that from > before the execute_before_dh_auto_configure target. That's true. My intent was that, since it's a hidden directory, it would help remind one that that directory gets created. It seems to've only caused confusion, so I'll pull it. > It seems like the Homepage should be the carl9170.fw firmware wiki page > instead of the carl9170 driver wiki page. > > https://wireless.wiki.kernel.org/en/users/drivers/carl9170.fw Good catch, I will fix that. > I would express the license of include/shared/fwcmd.h etc as GPL-2-only > && ISC rather than putting a copy of the ISC license in a comment. I agree that this is sensible. > bug-presubj isn't well wrapped. I'm not sure if wrapped or unwrapped is > the best option for this file though. Indeed, the documentation is rather old and terse and doesn't address this issue. I'll probably ask the Reportbug folks and send them a MR updating the docs. > Please ask upstream to make a new release, it has been a very long time > since the last one. I will do after making some of the following important changes. > Please ask upstream to update their copies of code from the Linux > kernel and other external sources to the latest versions. I can probably help them with this. > Please ask upstream to send FindUSB-1.0.cmake & libusb-zeropacket.diff > to libusb upstream and then remove them from carl9170fw. I will ask, but with all due respect, I think this is lower priority and that I'll have limited ability to help them. > Please ask upstream to delete FindPackageHandleStandardArgs.cmake, > since that is now available from cmake upstream and from Debian cmake. > Potentially cmake_minimum_required will need to be bumped for this. Will do. > Please ask upstream to include the copyright information > for carlfw/src/memcpy.S and carlfw/src/memset.S in the files. Especially since it is copyleft, I will definitely prioritize this. > Please ask upstream to update the COPYRIGHT file. I will be happy to do this. > Please send upstream some changes that would allow building the > upstream source using a pre-packaged toolchain like the Debian one. > > Please also figure out how to eliminate the other debian/rules > workarounds. I do not have a grasp,
[bts-link] source package src:linux
# # bts-link upstream status pull for source package src:linux # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #1000966 (http://bugs.debian.org/1000966) # Bug title: amdgpu: output to VR headset fails with "*ERROR* dc_stream_state is NULL for crtc '1'!" # * https://gitlab.freedesktop.org/drm/amd/-/issues/1856 # * remote status changed: (?) -> opened usertags 1000966 + status-opened thanks
Bug#990662: firmware-misc-nonfree: confirmation
Package: firmware-misc-nonfree Version: 20210315-3 Followup-For: Bug #990662 Hello, a confirmation of this bug # dmesg | grep -i nouv [2.688397] nouveau :01:00.0: vgaarb: deactivate vga console [2.690019] nouveau :01:00.0: NVIDIA G98 (298580a2) [2.725486] nouveau :01:00.0: bios: version 62.98.73.00.04 [2.745965] nouveau :01:00.0: fb: 256 MiB GDDR3 [2.825306] nouveau :01:00.0: DRM: VRAM: 256 MiB [2.825307] nouveau :01:00.0: DRM: GART: 1048576 MiB [2.825311] nouveau :01:00.0: DRM: TMDS table version 2.0 [2.825315] nouveau :01:00.0: DRM: DCB version 4.0 [2.825317] nouveau :01:00.0: DRM: DCB outp 00: 01000323 00010034 [2.825320] nouveau :01:00.0: DRM: DCB outp 01: 02011300 0028 [2.825324] nouveau :01:00.0: DRM: DCB outp 02: 02022386 0f200010 [2.825325] nouveau :01:00.0: DRM: DCB outp 03: 02022332 00020010 [2.825328] nouveau :01:00.0: DRM: DCB outp 04: 040333a6 0f200010 [2.825329] nouveau :01:00.0: DRM: DCB outp 05: 04033312 00020010 [2.825332] nouveau :01:00.0: DRM: DCB conn 00: 0040 [2.825334] nouveau :01:00.0: DRM: DCB conn 01: 0100 [2.825337] nouveau :01:00.0: DRM: DCB conn 02: 5246 [2.825338] nouveau :01:00.0: DRM: DCB conn 03: a346 [2.830444] nouveau :01:00.0: DRM: MM: using M2MF for buffer copies [2.921951] nouveau :01:00.0: DRM: allocated 1920x1200 fb: 0x5, bo 5b258a42 [2.922019] fbcon: nouveaudrmfb (fb0) is primary device [4.248388] nouveau :01:00.0: [drm] fb0: nouveaudrmfb frame buffer device [4.268803] [drm] Initialized nouveau 1.3.1 20120801 for :01:00.0 on minor 0 [ 53.775327] nouveau :01:00.0: firmware: failed to load nouveau/nv98_fuc084 (-2) [ 53.775333] nouveau :01:00.0: Direct firmware load for nouveau/nv98_fuc084 failed with error -2 [ 53.775345] nouveau :01:00.0: firmware: failed to load nouveau/nv98_fuc084d (-2) [ 53.775347] nouveau :01:00.0: Direct firmware load for nouveau/nv98_fuc084d failed with error -2 [ 53.775349] nouveau :01:00.0: msvld: unable to load firmware data [ 53.775351] nouveau :01:00.0: msvld: init failed, -19 [ 72.661417] nouveau :01:00.0: firmware: failed to load nouveau/nv98_fuc084 (-2) [ 72.661425] nouveau :01:00.0: Direct firmware load for nouveau/nv98_fuc084 failed with error -2 [ 72.661436] nouveau :01:00.0: firmware: failed to load nouveau/nv98_fuc084d (-2) [ 72.661438] nouveau :01:00.0: Direct firmware load for nouveau/nv98_fuc084d failed with error -2 [ 72.661440] nouveau :01:00.0: msvld: unable to load firmware data [ 72.661443] nouveau :01:00.0: msvld: init failed, -19 [ 227.014093] nouveau :01:00.0: fifo: CACHE_ERROR - ch 3 [Xorg[692]] subc 0 mthd 0060 data beef0201 [ 366.102466] nouveau :01:00.0: fifo: CACHE_ERROR - ch 3 [Xorg[692]] subc 3 mthd 1b00 data # lshw -C Display *-display description: VGA compatible controller product: G98M [Quadro NVS 160M] vendor: NVIDIA Corporation physical id: 0 bus info: pci@:01:00.0 version: a1 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress vga_controller bus_master cap_list rom configuration: driver=nouveau latency=0 resources: irq:28 memory:f500-f5ff memory:e000-efff memory:f200-f3ff ioport:df00(size=128) memory:c-d hth, Wim -- System Information: Debian Release: 11.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-9-amd64 (SMP w/2 CPU threads) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE=nl_BE:nl Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-misc-nonfree depends on no packages. firmware-misc-nonfree recommends no packages. Versions of packages firmware-misc-nonfree suggests: ii initramfs-tools 0.140 -- no debconf information
