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
Bug#1003406: RFS: simple-scan/40.7-1 -- Simple Scanning Utility
On Sun, Jan 09, 2022 at 06:49:08PM +0100, Jörg Frings-Fürst wrote: >Package name: simple-scan >Version : 40.7-1 > simple-scan (40.7-1) unstable; urgency=medium > . >* New upstream release. >* debian/copyright: > - Add year 2022 to myself. >* Declare compliance with Debian Policy 4.6.0.1 (No changes needed). >* New .gitignore. Hi! It fails to build: ../data/meson.build:11:5: ERROR: Function does not take positional arguments. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ At least spammers get it right: "Hello beautiful!". ⠈⠳⣄
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,
Bug#1003612: RFS: libview/0.6.6-3 [ITA] -- VMware's Incredibly Exciting Widgets
d/control: Remove or replace the Vcs-* fields.
Bug#1002645: RFS: pass-audit/1.1-1 [ITP] -- Pass extension for auditing your password repository (Python library)
On 2022-01-13 13:37:47, Antoine Beaupré wrote: > Any reason why you split the package in two binary packages? I don't see > why the python3-* package would really be useful outside of the > extension... Another thing is that I can't build the package here, it seems to fail on some weird gnupg error in the test suite. Log attached. other than that, things look somewhat sane. i'm a little worried about the security of the code, details in private (and sent to upstream on twitter). -- The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. - Douglas Adams (1952-2001) sbuild (Debian sbuild) 0.81.2 (31 January 2021) on curie.anarc.at +==+ | pass-audit 1.1-1 (amd64) Thu, 13 Jan 2022 18:40:21 + | +==+ Package: pass-audit Version: 1.1-1 Source Version: 1.1-1 Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: full I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-5e166863-e390-427a-9a82-74b7ee9909d6' with '<>' I: NOTICE: Log filtering will replace 'build/pass-audit-GM6x6t/resolver-ZffJKv' with '<>' +--+ | Update chroot| +--+ Get:1 https://deb.debian.org/debian unstable InRelease [165 kB] Get:2 https://deb.debian.org/debian unstable/main Sources.diff/Index [63.6 kB] Get:3 https://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [63.6 kB] Get:4 https://deb.debian.org/debian unstable/main Sources T-2022-01-13-1402.41-F-2022-01-13-0804.32.pdiff [17.4 kB] Get:4 https://deb.debian.org/debian unstable/main Sources T-2022-01-13-1402.41-F-2022-01-13-0804.32.pdiff [17.4 kB] Get:5 https://deb.debian.org/debian unstable/main amd64 Packages T-2022-01-13-1402.41-F-2022-01-13-0804.32.pdiff [33.0 kB] Get:5 https://deb.debian.org/debian unstable/main amd64 Packages T-2022-01-13-1402.41-F-2022-01-13-0804.32.pdiff [33.0 kB] Fetched 343 kB in 5s (62.6 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following packages will be upgraded: cpp-11 g++-11 gcc-11 gcc-11-base libasan6 libatomic1 libcc1-0 libgcc-11-dev libgcc-s1 libgomp1 libitm1 liblsan0 libquadmath0 libstdc++-11-dev libstdc++6 libtsan0 libubsan1 17 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 48.7 MB of archives. After this operation, 47.1 kB disk space will be freed. Get:1 https://deb.debian.org/debian unstable/main amd64 libcc1-0 amd64 11.2.0-14 [47.1 kB] Get:2 https://deb.debian.org/debian unstable/main amd64 libgomp1 amd64 11.2.0-14 [106 kB] Get:3 https://deb.debian.org/debian unstable/main amd64 libitm1 amd64 11.2.0-14 [26.1 kB] Get:4 https://deb.debian.org/debian unstable/main amd64 libatomic1 amd64 11.2.0-14 [9044 B] Get:5 https://deb.debian.org/debian unstable/main amd64 libasan6 amd64 11.2.0-14 [2050 kB] Get:6 https://deb.debian.org/debian unstable/main amd64 liblsan0 amd64 11.2.0-14 [886 kB] Get:7 https://deb.debian.org/debian unstable/main amd64 libtsan0 amd64 11.2.0-14 [2016 kB] Get:8 https://deb.debian.org/debian unstable/main amd64 libubsan1 amd64 11.2.0-14 [835 kB] Get:9 https://deb.debian.org/debian unstable/main amd64 libquadmath0 amd64 11.2.0-14 [144 kB] Get:10 https://deb.debian.org/debian unstable/main amd64 gcc-11-base amd64 11.2.0-14 [207 kB] Get:11 https://deb.debian.org/debian unstable/main amd64 libstdc++6 amd64 11.2.0-14 [577 kB] Get:12 https://deb.debian.org/debian unstable/main amd64 g++-11 amd64 11.2.0-14 [10.2 MB] Get:13 https://deb.debian.org/debian unstable/main amd64 libstdc++-11-dev amd64 11.2.0-14 [1979 kB] Get:14 https://deb.debian.org/debian unstable/main amd64 libgcc-11-dev amd64 11.2.0-14 [2356 kB] Get:15 https://deb.debian.org/debian unstable/main amd64 gcc-11 amd64 11.2.0-14 [18.1 MB] Get:16 https://deb.debian.org/debian unstable/main amd64 cpp-11 amd64 11.2.0-14 [9151 kB] Get:17 https://deb.debian.org/debian unstable/main amd64 libgcc-s1 amd64 11.2.0-14 [42.0 kB] debconf: delaying package configuration, since apt-utils is not installed Fetched 48.7 MB in 4s (13.6 MB/s) (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60%
Bug#1002645: RFS: pass-audit/1.1-1 [ITP] -- Pass extension for auditing your password repository (Python library)
Any reason why you split the package in two binary packages? I don't see why the python3-* package would really be useful outside of the extension... a. -- Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas. - Sébastien Faure
Bug#1002645: RFS: pass-audit/1.1-1 [ITP] -- Pass extension for auditing your password repository (Python library)
On 2021-12-26 16:07:47, Thomas Perret wrote: > I am looking for a sponsor for my package "pass-audit". Please note that > I would like, if possible, a sponsor that could help me in the process > of becoming a Debian Developer (I'm currently a Debian Maintainer). > Ideally, this would require reviewing some of my previous work[0], lead > me in the tasks I should do before applying for DD and advocate for me > in this process. Hi, I'm not sure I have the cycles to review your previous work (and btw the [0] reference seems to be missing), but I am really interested in this package so I'll do a quick audit of the code and review of your work and report back here shortly. a. -- Use for yourself little but give to others much. - Albert Einstein
Bug#1003612: RFS: libview/0.6.6-3 [ITA] -- VMware's Incredibly Exciting Widgets
On Wed, 12 Jan 2022 16:04:57 + Ileana Dumitrescu wrote: Changes since the last upload: libview (0.6.6-3) unstable; urgency=medium . [ Ileana Dumitrescu ] . * New maintainer (Closes: #674884) * debian/control: Updated to dh version 13 * debian/copyright: Updated to dep5 version 1.0 format * debian/compat: Removed to update dh version * debian/rules: Updated to use dh $@ and run on all architectures (Closes: #727446, #744625, #976498) Does this close #998924 as well? If not, there is no point to upload this. . [ Andreas Moog ] . * debian/patches: Added patch to fix libview.pc (Closes: #650253) Please consider writing an answer to #956789 on why you think this package should be kept around.
Bug#1003464: RFS: kic/2.4c-1 [QA] [RC] -- Enhanced KIC layout editor
Control: tag -1 pending Control: tag 688189 pending Control: tag 999088 pending On 13/01/2022 04.21, Hugo Torres wrote: thanks for the guidance. I have already made the suggested changes and correction of FTBFS. Looks good. I'll wait for feedback on my autobuild whitelist request and upload afterwards. Thanks for your work on kic! Andreas
