I'll look at reviewing this and sponsoring marlin... look for a full review in a while.

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- Large documentation must go in a -doc subpackage. Large could be size
  (~1MB) or number of files.
  Note: Documentation size is 11069440 bytes in 102 files.
  See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_documentation

- build.log has:
Client platform:   Linux
GUI support:       QT not found, disabled
native BT support: Bluez not found, disabled
Jansson library:   system library not found, using local library
Lua library:       system library not found, using local library
Python3 library:   Python3 not found, disabled
Readline library:  enabled
Whereami library:  system library not found, using local library
Lua SWIG:          wrapper found

Is it worth enabling GUI support, native bt support and python3 support?

Can you try and use system library versions of jansson ( BuildRequire: jansson-devel )
Lua ( BuildRequire: lua-devel ), and Whereami (BuildRequires: whereami).

- I think the correct lincese tag here is not 'GPL-3.0' but 'GPLv3+'

- you should own /usr/share/proxmark3 directory. either a %dir in files or
remove the /* at the end so it includes the directory.

- Why the:
%global debug_package %{nil}
%define __strip /bin/true
?

- Is it worth running the tests in %check? If they don't need internet it might be worth
enabling them.

===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: If your application is a C or C++ application you must list a
     BuildRequires against gcc, gcc-c++ or clang.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[?]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[?]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated", "GNU General Public License v3.0 or
     later", "*No copyright* GNU General Public License v3.0 or later",
     "*No copyright* GNU General Public License, Version 2", "MIT License",
     "GNU General Public License, Version 2", "*No copyright* [generated
     file]", "GNU General Public License v2.0 or later", "BSD 2-Clause
     License", "Apache License 2.0", "GNU Lesser General Public License
     v3.0 or later", "BSD 3-Clause License", "BSD 2-clause NetBSD License
     BSD 2-Clause License", "MIT License GNU General Public License,
     Version 2", "*No copyright* Public domain", "*No copyright* Do What
     The Fuck You Want To Public License, Version 2", "*No copyright*
     Apache License 2.0". 1039 files have unknown license. Detailed output
     of licensecheck in /home/kevin/2057302-proxmark3/licensecheck.txt
[?]: Package requires other packages for directories it uses.
     Note: No known owner of /usr/share/proxmark3
[?]: Package must own all directories that it creates.
     Note: Directories without known owners: /etc/udev,
     /usr/share/proxmark3, /etc/udev/rules.d
[x]: %build honors applicable compiler flags or justifies otherwise.
[?]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[x]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[?]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[x]: Package contains systemd file(s) if in need.
[?]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: Package does not own files or directories owned by other packages.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package must not depend on deprecated() packages.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[x]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[-]: Package should compile and build into binary rpms on all supported
     architectures.
[?]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Spec use %global instead of %define unless justified.
     Note: %define requiring justification: %define __strip /bin/true
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.

===== EXTRA items =====

Generic:
[!]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
     Note: Arch-ed rpms have a total of 52899840 bytes in /usr/share
     proxmark3-4.14831.1-1.fc37.x86_64.rpm:52899840
     See:
     https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Guidelines
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Cannot parse rpmlint output:


Rpmlint (installed packages)
----------------------------
Cannot parse rpmlint output:


Source checksums
----------------
https://github.com/s00se/proxmark3/archive/refs/tags/v4.14831.1.tar.gz :
  CHECKSUM(SHA256) this package     : dbb1c4a17269ab176fa5807b67f3a3ea35c4bfd397cef35840ebc8cf6612bce5
  CHECKSUM(SHA256) upstream package : dbb1c4a17269ab176fa5807b67f3a3ea35c4bfd397cef35840ebc8cf6612bce5


Requires
--------
proxmark3 (rpmlib, GLIBC filtered):
    /usr/bin/bash
    /usr/bin/perl
    /usr/bin/python3
    bzip2-libs
    libbz2.so.1()(64bit)
    libc.so.6()(64bit)
    libgcc_s.so.1()(64bit)
    libgcc_s.so.1(GCC_3.0)(64bit)
    libgcc_s.so.1(GCC_3.4)(64bit)
    libm.so.6()(64bit)
    libreadline.so.8()(64bit)
    libstdc++.so.6()(64bit)
    readline
    rtld(GNU_HASH)



Provides
--------
proxmark3:
    proxmark3
    proxmark3(x86-64)



Generated by fedora-review 0.7.6 (b083f91) last change: 2020-11-10
Command line :/usr/bin/fedora-review -b 2057302
Buildroot used: fedora-rawhide-x86_64
Active plugins: C/C++, Shell-api, Generic, Perl
Disabled plugins: Java, Python, Haskell, fonts, R, SugarActivity, PHP, Ocaml
Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH

Hi, thank you for taking a look at this.

> Is it worth enabling GUI support, native bt support and python3 support?

Yes, thanks for catching that. Updated in spec.

> Can you try and use system library versions of jansson ( BuildRequire: jansson-devel ) Lua ( BuildRequire: lua-devel ), and Whereami (BuildRequires: whereami).

lua5.2 is a hard requirement right now so using internal library.
I couldn't find a devel package for whereami (usually libwhereami), so using internal.

> I think the correct lincese tag here is not 'GPL-3.0' but 'GPLv3+'

Updated in spec.

> you should own /usr/share/proxmark3 directory. either a %dir in files or
remove the /* at the end so it includes the directory

Updated in spec.

> Why the: 
%global debug_package %{nil}
%define __strip /bin/true

There are some device firmware files built by arm-none-eabi-gcc which don't include build-id and they fail during stripping. Please let me know if there's a better/preferred way of doing this, I wasn't sure.

> Is it worth running the tests in %check? If they don't need internet it might be worth
enabling them.

There are some checks which require packages/package version not available: namely openssl backwards support for secp128r1

New spec:
https://raw.githubusercontent.com/s00se/proxmark3/v4.14831.1/packaging/fedora/proxmark3.spec

New COPR builds:
https://copr.fedorainfracloud.org/coprs/s00se/proxmark3/build/3707171/

Thanks. 

> There are some device firmware files built by arm-none-eabi-gcc which don't include build-id and they fail during stripping. Please let me know if there's a better/preferred way of doing this, I wasn't sure.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Debuginfo/

Could you perhaps chmod -x them? Or do they need to be executable?

> There are some checks which require packages/package version not available: namely openssl backwards support for secp128r1

Can you enable most of the tests, and just disable those?

> Could you perhaps chmod -x them? Or do they need to be executable?

Thanks for the tip, I added the entries as such under %install

chmod -x %{buildroot}/usr/share/proxmark3/firmware/fullimage.elf

but brp-strip still tries to strip them and fails to detect their format. I'm not sure if this is because they are already getting stripped in the cross compilation process? If so, skipping the strip seems more "stay upstream" but if a patch is preferred, please advise.

> Can you enable most of the tests, and just disable those?

The tests are grouped in such a way that I thought it would be preferred to stay close to upstream again and just not use the optional checks.

I use and work with the moving master branch, there are out of band checks before releases are tagged, which include confirming functionality. I'm hoping, as a package maintainer for Fedora, to upkeep and ensure that all releases matching the upstream releases remain functional.

(In reply to marlin.soose from comment #5)
> > Could you perhaps chmod -x them? Or do they need to be executable?
> 
> Thanks for the tip, I added the entries as such under %install
> 
> chmod -x %{buildroot}/usr/share/proxmark3/firmware/fullimage.elf
> 
> but brp-strip still tries to strip them and fails to detect their format.
> I'm not sure if this is because they are already getting stripped in the
> cross compilation process? If so, skipping the strip seems more "stay
> upstream" but if a patch is preferred, please advise.

Would it be worth making a -firmware subpackage and making it noarch?

Assuming the firmware is arch independent and builds the same on different arches?

> > Can you enable most of the tests, and just disable those?
> 
> The tests are grouped in such a way that I thought it would be preferred to
> stay close to upstream again and just not use the optional checks.
> 
> I use and work with the moving master branch, there are out of band checks
> before releases are tagged, which include confirming functionality. I'm
> hoping, as a package maintainer for Fedora, to upkeep and ensure that all
> releases matching the upstream releases remain functional.

Sure, it's optional. If it's easy to run some sanity tests at build time I think it's useful, but if not, the upstream tests at release time are better than no tests at all for sure. ;)

> Would it be worth making a -firmware subpackage and making it noarch? Assuming the firmware is arch independent and builds the same on different arches?

The client software prefers using "matched" firmware on the device, so building and including a firmware image with sane defaults will allow this, without requiring users to install a separate package. The firmware is small and is ideally included in the package so users can 'hit the ground running'.

The spec builds clean once strip is overridden and debug disabled, which I think is the least intrusive way to do this.

Are there any other blockers or changes to be made?

I made some further changes to the SPEC

https://download.copr.fedorainfracloud.org/results/s00se/proxmark3/fedora-35-x86_64/03823400-proxmark3/proxmark3.spec

https://copr.fedorainfracloud.org/coprs/s00se/proxmark3/build/3823400/

Sorry for the delay here... ;( 

I'm ok with everything except I am not a fan of the debuginfo being turned off.
Perhaps we can use one of the other find-debuginfo options... 

Perhaps we could use -p?

"The -p argument is an grep -E -style regexp matching the a file name,and must not use anchors (^ or $)."

If there's a regex that could be all the non firmware names. I'll try and play around with it...

I'd like to understand more about why turning off debug is not recommended, but a regex to hit every single file except "fullimage/bootrom.elf" is okay. Why is "%global debug_package %{nil}" available if it shouldn't be used? Or, rather, when is it appropriate to use this included option?

I have moved removing the executable bit down in the %install chain and this seems to work but I don't quite understand why, since these files should already be built by %build, nor why I can't use a macro for the first few operations here:

%install
chmod -x ./client/luascripts/examples/example_cmdline.lua
chmod -x ./client/cmdscripts/rdv4_init_extflash.cmd
chmod -x ./client/pyscripts/xorcheck.py
chmod -x ./client/cmdscripts/example.cmd
make %{?_smp_mflags} install PREFIX=%{buildroot}/usr UDEV_PREFIX=%{buildroot}/etc/udev/rules.d/
chmod -x %{buildroot}/usr/share/proxmark3/firmware/fullimage.elf
chmod -x %{buildroot}/usr/share/proxmark3/firmware/bootrom.elf

but fails with:

File listed twice: /usr/share/doc/proxmark3
Empty %files file /builddir/build/BUILD/proxmark3-4.14831/debugsourcefiles.list

Full spec: https://download.copr.fedorainfracloud.org/results/s00se/proxmark3/fedora-35-x86_64/03954951-proxmark3/proxmark3.spec

(In reply to marlin.soose from comment #10)
> I'd like to understand more about why turning off debug is not recommended,
> but a regex to hit every single file except "fullimage/bootrom.elf" is okay.
> Why is "%global debug_package %{nil}" available if it shouldn't be used? Or,
> rather, when is it appropriate to use this included option?

Well, the guidelines aren't 100% clear here... I guess having usable debuginfo is a "SHOULD" not a "MUST".
It annoys me because I can see someone hitting a crash and trying to debug it and getting stuck. 
I know thats unlikely. 

> 
> I have moved removing the executable bit down in the %install chain and this
> seems to work but I don't quite understand why, since these files should
> already be built by %build, nor why I can't use a macro for the first few
> operations here:

Well, until you run the 'make install' there's nothing installed. ;) 
So, if you move those to after make install you should be able to change them in the installed buildroot

> 
> %install
> chmod -x ./client/luascripts/examples/example_cmdline.lua
> chmod -x ./client/cmdscripts/rdv4_init_extflash.cmd
> chmod -x ./client/pyscripts/xorcheck.py
> chmod -x ./client/cmdscripts/example.cmd
> make %{?_smp_mflags} install PREFIX=%{buildroot}/usr
> UDEV_PREFIX=%{buildroot}/etc/udev/rules.d/
> chmod -x %{buildroot}/usr/share/proxmark3/firmware/fullimage.elf
> chmod -x %{buildroot}/usr/share/proxmark3/firmware/bootrom.elf


> but fails with:
> 
> File listed twice: /usr/share/doc/proxmark3

Are any of the above docs? Docs are copied in install too...

> Empty %files file
> /builddir/build/BUILD/proxmark3-4.14831/debugsourcefiles.list

So, it can't find the sources (.c/.h/etc). 

> Full spec:
> https://download.copr.fedorainfracloud.org/results/s00se/proxmark3/fedora-35-
> x86_64/03954951-proxmark3/proxmark3.spec

Thanks, I really hope to have time to look this weekend...

ok, circling back around. The doc issue is a nice confusing one. ;) 

Basically the %doc macro takes the listed files/dirs from the buildroot and also _installs them_ in /usr/share/doc/name/ in the installroot. 
The make install step also appears to install docs there, so rpmbuild sees them listed twice. The best way forward IMHO is to delete them at the end of install and let the %doc macro install them for you. 

So:

--- proxmark3.spec.1    2022-04-04 17:21:21.000000000 -0700
+++ proxmark3.spec      2022-04-16 12:03:29.704848924 -0700
@@ -19,8 +19,8 @@
 %autosetup
 
 %build
-make %{?_smp_mflags} clean
-make %{?_smp_mflags} SKIPLUASYSTEM=1
+make %{?_smp_mflags} V=1 clean
+make %{?_smp_mflags} V=1 SKIPLUASYSTEM=1
 rm -rf %{buildroot}/doc/datasheets/
 rm -rf %{buildroot}/doc/original_proxmark3/
 
@@ -29,9 +29,10 @@
 chmod -x ./client/cmdscripts/rdv4_init_extflash.cmd
 chmod -x ./client/pyscripts/xorcheck.py
 chmod -x ./client/cmdscripts/example.cmd
-make %{?_smp_mflags} install PREFIX=%{buildroot}/usr UDEV_PREFIX=%{buildroot}/etc/udev/rules.d/
+make %{?_smp_mflags} V=1 install PREFIX=%{buildroot}/usr UDEV_PREFIX=%{buildroot}/etc/udev/rules.d/
 chmod -x %{buildroot}/usr/share/proxmark3/firmware/fullimage.elf
 chmod -x %{buildroot}/usr/share/proxmark3/firmware/bootrom.elf
+rm -rf %{buildroot}%{_datadir}/doc/proxmark3
 
 %files
 %{_sysconfdir}/udev/rules.d/77-pm3-usb-device-blacklist.rules
@@ -41,7 +42,6 @@
 %{_bindir}/pm3-flash-bootrom
 %{_bindir}/pm3-flash-fullimage
 %{_bindir}/proxmark3
-%{_docdir}/proxmark3
 %{_datadir}/proxmark3
 
 %license LICENSE.txt

I also think it would be good to pass V=1 to make here to get the full compile logs. 

Anyhow, can you take a look at that and confirm it makes sense? Then, I don't see any more blockers here, so I can go ahead and sponsor you and we can get the package in. ;)

Ah okay, definitely confusing if one doesn't know the macro actually has a function too. Thanks for clarifying.

With your recommend changes to the spec, the only remaining build error on f34+f35 -- but not failing on f35+rawhide:

RPM build errors:                                                                                                      
error: Empty %files file /builddir/build/BUILD/proxmark3-4.14831/debugsourcefiles.list

https://copr.fedorainfracloud.org/coprs/s00se/proxmark3/build/4229655/

ok, thats due to things not building with the correct compiler flags. ;( 

In f36+ thats fixed automatically by https://fedoraproject.org/wiki/Changes/SetBuildFlagsBuildCheck 
but in older releases it's not there. 

Adding: 

export CFLAGS="%{optflags}"

before the make calls fixes it here. Or you could try and use %make_build and %make_install macros. I tried that at first and they didn't seem to pass things correctly, but you might give it a try and see if you can get them to work.

I'm good with setting CFLAGS, when f35 packages are ceased and it's unnecessary, it'll be a simple removal.

This builds from f34 to rawhide now, thank you! https://copr.fedorainfracloud.org/coprs/s00se/proxmark3/build/4248493/

Spec file: https://download.copr.fedorainfracloud.org/results/s00se/proxmark3/fedora-36-x86_64/04248493-proxmark3/proxmark3.spec

So if everything is good now, I think I need to be approved for access to the packager group. Should this be co-maintained or solo? Having this help along the way has really been great.

Looks good. Thanks for your patience. :) 

I've added you to the packager group. 

You should be able to continue the process at https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_New_Contributors/#add_package_to_source_code_management_scm_system_and_set_owner 

If you have any questions at all, please feel free to ask me in email, matrix/irc (my nick is nirik), or here.

(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/proxmark3

FEDORA-2022-bde1067f44 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-bde1067f44

FEDORA-2022-e9e7e2af1b has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-e9e7e2af1b

FEDORA-2022-a85f46c0cb has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-a85f46c0cb

FEDORA-2022-6ff29d37f8 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6ff29d37f8

FEDORA-2022-a85f46c0cb has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2022-a85f46c0cb \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-a85f46c0cb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-6ff29d37f8 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2022-6ff29d37f8 \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6ff29d37f8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-e9e7e2af1b has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2022-e9e7e2af1b \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e9e7e2af1b

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I'm interested in trying this out in Fedora 35. I have a brand new, unflashed Proxmark3 "Easy" device. I installed your package as per comment #24, and I ran:

```
$ proxmark3 /dev/ttyACM0
```

(because that's the only device out there, and also it matches what's happening in dmesg when plugging it in)

It said, "⚠️  ERROR: invalid serial port /dev/ttyACM0"

So I ran it as root instead, and it said:

```
# proxmark3 /dev/ttyACM0 
[=] Session log /root/.proxmark3/logs/log_20220422.txt
[=] Using UART port /dev/ttyACM0
[!!] 🚨 ERROR: cannot communicate with the Proxmark
unknown command:: 0x61334d50
```

Now, my question is, how is your package supposed to be interacted with, with various pieces of hardware, particularly the "Proxmark3 Easy" ready-to-use kit? Do I need to flash it the first time, or everytime, and can I do it with your package without any extra stuff? I read through various guides¹ ² ³ but couldn't really figure out an answer for myself. Any tips there? I would love to be sure it can work safely with my device so that I can test it further than "can I run the binary" :)

I've read through...
¹: https://forum.dangerousthings.com/t/getting-started-with-the-proxmark3-easy/9050
²: https://forum.dangerousthings.com/t/proxmark-3-easy-and-linux-call-for-help/7011
³: https://forum.dangerousthings.com/t/troubles-with-the-proxmark3-easy/10913

...but most guides are very Windows-centric, or, otherwise, written for people who build and run their own thing from the github repository. I'm wondering how the interaction is meant to be, especially for the firmware/rom side of things, with your Fedora package.

> Do I need to flash it the first time, or everytime, and can I do it with your package without any extra stuff?

You sure can. This Fedora package includes firmware images (/usr/share/proxmark3/firmware/) which you can flash using `pm3-flash-all` to update the bootloader and FPGA -- you can use `pm3-flash-bootrom` and `pm3-flash-fullimage` respectively, to update them separately if for some reason you require it. You only need to flash the device when you want to update the firmware, which for this package, will only be necessary when a new release is tagged.

You can use `pm3` (or `proxmark3` with the port as you did) which will auto-detect your port and connect to the device. You can add your user to the `dialout` group in order to access the device without using root.

> Any tips there? I would love to be sure it can work safely with my device so that I can test it further than "can I run the binary" :)

Just update the firmware and I suspect you will be able to connect to, and interact with the device, as expected, and can continue testing. Also, thank you for testing and providing feedback!

FEDORA-2022-e9e7e2af1b has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-6ff29d37f8 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2022-a85f46c0cb has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.